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The A-party generates 1 LOGOUT * according to the criteria 
and with the structure stated in Appendix A. 



Dialogue 14.1; 
' Subscription initiates log-out. 



A NETWORK 
' LOGOUT" 1 



Dialogue 14.2; 

Network initiates logout. 

The subscription has sent a LOGINREQ from a terminal but 
is still registered as logged-in to another terminal. The 
network will then send LOGOOTORD to the old terminal 
according to the criteria and with' the format stated in 
Appendix A. 

The personal subscription should immediately be deleted 
from the B-party's flexlist. 



NETWORK B 
' LOGOOTORD ' 1 



If the network has sent a LOGOOTORD and the old terminal 
did not receive it, the LOGOOTORD is repeated when the 
subscriber sends a message next time. 



ifcprod 



A-J92S1534 



Exhibit 



Cantel Mobitex- 



52/1056 - A 296 5171/2 Ue 



1990-02-23 A 



15 ACTIVATION 

The A-party generates ' ACTIVE 1 according to the criteria 
and with the format stated in Appendix A. 



Dialogue 15.1: 

Activation is approved and the mailbox is empty. 



Dialogue 15.2: 

Activation is approved and there are packets in the 
mailbox, both for the terminal and the personal 
subscription. 




MSG 1 and 2 are packets (HPAK) that has been stored in the 
network mailbox while the terminal has been inactive. 
Each packet sent out from the mailbox is delayed a certain 
time in order not to overload the terminal. 
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16 INACTIVATION 



The A party generates ' INACTIVE 1 according to the criteria 
and with the format stated in Appendix A. 



Dialogue 16.1: 
Inactivation. 



NETWORK 
' INACTIVE ' 1 
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17 DIE - LIVE 



The network generates 'DIE' and "LIVE* according to the 
criteria and with the format stated in Appendix A. 

when the terminal receives 'DIE' it is not allowed to send 
any user traffic to the network, until a 'LIVE* has been 
received. Dser traffic is defined. as packets included in 
the packet classes; PSDBCOM, PSOSCOM and CSOBCOM. The 
terminal may send DTESEHV packets. 



Dialogue 17.1; 

The terminal may not send user traffic. 



NETWORK B 
'DIE' 



'DIE' is stored in the network mailbox if the B-party is 
not active. The packet is sent out according to Dialogue 
15.2 when the B party is active again. 



Dialogue 17.2 ; 

The terminal may send packets again. 



1 LIVE' is stored in the network mailbox if the B-party is 
not active. The packet is sent out according to dialogue 
15.2 when the B-party is active again. 
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' Dialogue 18.1: 

The network requests the terminal to send a ROAM packet. 

The network generates 1 ROAHORD ' according to the criteria 
and with the format stated in Appendix A. 



1 ROAMORD 1 1 



The B-party generates 'ROAM' 2 according to the criteria 
and with the format stated in Appendix A. 



Dialogue 18.2; 

The A-party generates 'ROAM' spontaneously according to 
the criteria and with the format stated in Appendix A. A 
spontaneously generation of a ROAM packet is initiated 
from the roaming procedure described in the mobile 
terminal data link layer. 
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19 RE-DIRECTION OP EMERGENCY MESSAGES 

This is used when the emergency messages should be sent to 
the alternative emergency receiver. 

The A party generates 'VICESOSRX' according to the 
criteria and with the format stated in Appendix A. 



Dialogue 19.1: 

The re-direction is approved. 

A NETWORK 
'VICESOSRX' 1 



Dialogue 19.2: 

The 'VICESOSRX 1 is returned from the network. 



■VICESOSRX' 2 



a) Re-direction cannot/may not take place. 

' VICESOSRX ' 2 is returned with traffic state = ILLEGAL 

b) The network is overloaded. 

' VICESOSRX ' 2 is returned with traffic state = CONGEST 

c) A technical fault may have occurred. 

' VICESOSRX 1 2 is returned with traffic state = ERROR 
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20 CANCEL RE-DIRECTION OF EMERGENCY MESSAGES 
Dialogue 20.1: 

The re-direction is cancelled. 



NETWORK 
■SOSRX' 1 



Dialogue 20.2: 

The cancellation of the re-direction cannot/may not be 
accepted. 



' SOSRX' 2 is returned with traffic state = ILLEGAL 
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21 UPDATING GROUPLIST 




Dialoque 21.1: 





The network generates 'GROUPLIST* according to the 
criteria and with the format stated in Appendix A. 



NETWORK 1 
•GROOPLIST' 1 



'GROUPLIST' is stored in the network mailbox if the B 
party is not active. The packets are sent out according to 
dialogue 15.2 when the B party is active again. 
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22 UPDATING THE LIST OF PERSONAL SUBSCRIPTIONS 



Dialogue 22.1: 

The network generates * FLEXREQ" according to the criteria 
and with the format stated in Appendix A. 



' FLEXLIST' 2 



' FLEXLIST ' is generated according to the criteria and with" 
the format stated in Appendix A. 



Dialogue 22.2: 

The network generates ' FLEXLIST' according to the criteria 
and with -the format stated in Appendix A. 



' FLEXLIST '1 



' FLEXLIST ' is stored in mailbox if the B party is not 
active. The packet is sent out according to dialogue 15.2 
when the B party is active again. 
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23 TECHNICAL INFORMATION 



Dialogue 23.1; 



The network generates ' INFOREQ ' according to the criteria 
and with the format stated in Appendix A. 



24 TIME INFORMATION 



Dialogue 24.1: 



The network generates "TIME' according to the criteria and 
with the format stated in Appendix A. 
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25 UPDATING AHEALIST 
Dialogue 25.1: 

The network generates 'AREALIST' according to the criteria 
and with the format stated in Appendix A. 



NETWORK 

'AREALIST' ' 1 



•AREALIST' is stored in the network mailbox if the B party 
is not active. The packets are sent out according to 
dialogue 15.2 when the B party is active again. 



26 ELECTRONIC SERIAL NUMBER CHECK 



Dialogue 26.1; 

The network generates ' ESNREQ * according to the criteria 
and with the format stated in Appendix A. 
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MOBITEX 

Network layer for terminals 
Appendix C. Logical description 



ABSTRACT 

This document contains the logical description for the network 
layer for mobile terminals connected to the MOBITEX system. 
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1 GENERAL 



1.1 DATA FLOW DIAGRAM 

The data Elow diagram below shows the interaction between the 
network layer and the other two layers; the data link layer and the 
application layer. 



| Application Layer ( APP ) | 




.3 . i 


r 4 



NETWORK LAYER 





. ' 1 


r 2 


| Data Link Layer ( LINK ) | 



Signals to/from Data Link Layer. 

-1- MPAK^transmitted, MPAK_not_transmitted, MPAK_received, 
roaming, activation 

-2- MPAK_to_transmit, MPAK_to_retransmit, speech_on, speech_off , 
order_to_return_MPAK, group_list_information, 
area_list_information 

Signals to/from Application Layer. 

-3- MPAK_received, returned_MPAK_with_code, die, live,- buffer_full 

-4- MPAK_to transmit, hook_6n, hook_off, power_off, 
manual Jiiode on, mpak to retransmit 
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1 . 2 TERMINOLOGY 
P_ / F_ 

input_signal 

wait_for_input_signal 
save_signal 



ignore_signal 
grouplist 
flexlist 
permanent_list 

g r oupl i s t_r ecei ved_f lag 

active_delay_power_up 
active_delay_lost_contact 
power_of f_ready 



In this logical description, all 
procedures starts with "P_", and all 
"functions with "F_" . 

The network layer has an input queue. A 
signal from this input queue is called' 
"input_signal". 

The. network layer is waiting until' un 
input_signal is available. 

Restoring the signal into the queue. 
This is done when you expect a certain 
signal. By repeating input_signal and 
save_signal, you can search in the 
input queue for certain signals. All 
saved signals are available when an 
input_signal fallows after an 
- input_signal- without any save_signal 
between. See chapter 'Queue handling'. 

No further handling of this signal, 
except that the signal should be 
'deleted. 

Area where group MAN are stored. This 
list should be stored also during power 
off. 

Area where personal subscription MAN 
are stored. This list should be stored 
also during power off. 

Total area to be continuously stored. 
In this area terminal MAN, serial 
number, group list, flexlist, die_state 
and live_state are stored. The checksum 
is calculated based on this list. 

Indication of a correct permanent list 
and that a MPAK: GROUPLIST is received 
or not. 

Activation delay concerning power-up 
and manual radio mode. See Rl-06. 

Activation delay concerning lost 
contact. See Rl-06. 

Flag to indicate that the network layer 
is ready to be closed. 



Exhibit 2, p. 415 



Caritel Mohitex~ 



53/1056-A 296 5171/2 Ue 



1990-02-23 ft [MTS09C.2 



raanual_mode 

buffer_full_flag 
emergency_flag 



Flag to indicate that the mobile 
station is in manual mode. 

Indication of buffer full. 

Indication of an activated emergency. 
When application layer receive an 
emergency signal, this flag is raised. 
Now the network layer can handle the 
priority of emergency in the terminal. 
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1.2 SIGNALS 

MPAK_to_transmit 

MPAKjreceived 

MPAK_trarismitted 
MPAK_not_transmitted 
MPAK_t o_r et r ansmi t 

roaming 
activation 

speech_on 
speech_of f 
order_to_return_MPAK 

group_list_information 
area_list_information 
returned MPAK with code 



MPAK received from the application 
layer or MPAK to the data link layer to 
be transmitted. 

MPAK received by the data link layer or 
MPAK to. be sent to the application 
layer. 

MPAK successfully transmitted by the 
data link layer. 

MPAK not transmitted by the data link 
layer . 

MPAK from the application layer to the 
data link layer to be retransmitted 
(special treatment in the data link - 
layer). 

Order to the network layer to send an 
MPAK: ROAM. 

Start activation timeout (after power- 
on or lost contact with base} given in 
Rl-06. 

Order to the data link layer to set 
mode speech_on. 

Order to the data iink layer to set 
mode speech_off. 

Order to the data link layer to stop 
sending an MPAK, and return the MPAK to 
the network layer. 

Group list information to the data link 
layer . 

Area list information to the data link 
layer . 

Returned MPAK with code information 
from the network layer. The code shows 
why the MPAK was returned. 
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hodkjon 
hook_of f 
die 



buffer full 



power_off 
power_of f _t imeout 
iuanual_mode_on 
manual_mode on timeout 



Hook_on signal from the application 
layer. 

Hook_off signal from the application 
'layeF. 

A signal informing that the network 
layer has received an MPAK: DIE. All 
user traffic is stopped and returned to 
the application layer. 

A signal informing that the network 
layer has received" an MPAK : LIVE . User 
traffic from the application layer can 
be handled. 

Queue for incoming messages is full. 
Incoming and outgoing traffic from/to 
the MOB I TEX network is stopped. The 
network layer tries to send 
MPAK: INACTIVE. Application layer is 
informed. When the message buffer has 
space for at least 6 messages, 
according to specification Rl-09, the 
buffer_full_flag is reset and incoming 
and outgoing traffic is resumed. 

The application layer wants to turn the 
network layer off.' The network layer 
tries to send an MPAK: INACTIVE. 

Internal timeout to indicate that the 
network layer is ready to be turned 
off. 

The application layer wants to turn 
over to manual radio mode. The network 
layer tries to send an MPAK: INACTIVE. 

Internal timeout to indicate that the 
network layer is ready to turn over to 
manual radio mode. 
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1.3 RETURNED HPAK WITH CODE 



NOT_SENT SPEECH 



NOT ! 



'_DIE 



NOT_SENTJBOFFER_FULL 
INCORRECT 

PERSONAL_MAN_EXI ST 
PERSONAL_MAN_NOT_EXIST 
FLEXLIST FULL 



This MPAK has been correctly sent by the 
data link layer. 

This MPAK has not been correctly sent by 
the data link layer. • 

This MPAK has not been' sent because of 
speech state in the network layer. 

This MPAK has not been sent because of die 
state in the network layer. 

This MPAK has not been sent because of 
buffier_full state in the network layer. 

Received MPAK from the application layer, 
do not have a correct format or is not 
allowed to be sent. 
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1 • 4 STATES 
idle 

die state 



sending_during_die 

link_busy 

sending_conreq 
stop_sending 

wait_for_hook_off_normal 
wait_for_hoofc_off_fast 
wait_for_hook_of f_group 

sending_conrea 

speech_notmal 
speech_group 

sending_discon 



Idle state 

•A received MPAK: DIE has ordered the 
mobile to this state. No outgoing user 
traffic is allowed. A received 
MPAK: LIVE orders the mobile to idle 
state. 

Only MPAK of class DTESERV and 
MPAK:DISCON (CSUBCOM) can be sent 
during die_state. " 

The data link layer can only handle one 
packet at a time. In the present state, 
the data link layer is busy. 

The data link layer is busy sending 
speech request. 

The network layer has ordered the data 
link layer to stop sending present 
packet. The necwork layer is waiting 
until the data link layer Is ready. 

A normal speech request is received and 
the network layer is waiting for 
response from the 'application layer. 

A fast speech request is received and 
the network layer is waiting for 
response from the application layer. 

A group speech request is received and 
the network layer is waiting for 
response from the application layer. 

The data link layer is busy sending a 
hook_off signal (MPAK:CONREA) . 

The network layer is in speech state. 

The network layer is in group speech 
state. 

The data link layer is busy sending a 
hook_on signal ( MPAK :DISCON). 
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1.5 STATE DIAGRAM 



STOP 




SENDING 




WAIT FOR 


SENDING 




CONREA 




HOOK OFF XXX 



SPEECH 
NORMAL 



SENDING 
DISCON 



WAIT_FOR_HOOK_OFF_XXX can be in three different states depending on 
the received speech request, as follows: 



STATE 

WAIT_FOR_HOOK_OFF_NORMAIi 

WAIT_FOR_HOOK_OFF_FAST 
WAIT FOR HOOK OFF GROUP 



WHEN RECEIVING 

CONREQ, ADDCONREQ, SOSCONREQ or 



CONFAST, ADDCONFAST or SOSCONFAST 
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1.6 QUEUE HANDLING 
input queue: 



Input_signal: 
3 I 



1 c 



Save_3ignal: 



Input_signal and save_signal; 



Input_signal : 



Input_signal 



1 E 



input_queue_pointer 



input_queue_pointer+l 
signal available for user 



input_queue_pointer+l 
save_input_queuejpointer 



input_queuejpointer+2 
save_input_queue_pointer+l 
sa ve_i npu t_queue_poi n t e r 

input_queue_pointer+3 
signal available for user 
sa ve_i npu t_queue_po i nt e r + 1 
save_input_queue_j3ointer 



input_queue_pointer+l 
signal available for user 
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2 LOGICAL DESCRIPTION 



2.1 Start of program 

This program have two different modes, MOBITEX mode and MANUAL mode. 
In MANUAL mode, the network layer is stopped. 

When MOBITEX mode is activated from MANUAL mode the network layer 
should be restarted. 



NETWORK LAYER 

P_actIvation handling 
next_state =~idle 
emergency_f lag = FALSE 
IF permanent_list is not correct THEN 
make MPAK BORN 

send MPAK_to_transmit to LINK 
next_stati" =~link_busy 
reset grouplist and flexlist 
set NOT grouplist_received_flag 

ENDIF 

LOOP 

IF manual mode THEN 

MOBITEX network_layer inactivated 

activated = FALSE 
- handle manual mode 
ELSE 

wait for input sig nal 
IF- emergency_fTag THEN 
P_lpok_for_emergency 
ENDIF 

CASE signal 

WHEN MPAK to transmit from APP 
P_MPAK~FROM_APP 

WHEN MPAK to retransmit from APP 
P_MPAK~TO~RETRANSMIT 

WHEN MPAK_received from LINK 
P_REC_MPAK_FROM_L INK 

WHEN MPAK_transmitted from LINK 
P_MPAK_TRANSMITTED 

WHEN MPAK not transmitted from LINK 
P_MPAK~NOT~TRANSMITTED 

WHEN hook on from APP 
P_HOOK~ON_handling 

WHEN hook off from APP 
P_HOOK~OFF_handling 

WHEN hook_off_timeout 
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P_t imeou t_handl i ng 




WHEN roaming from LINK 
P_roaming_handling 




WHEN activation from LINK 
P_activation_handling_link 


WHEN activation timeout 

P_activation~timeout_handling 


WHEN power_off from APP 
Pjpowe r _of f _handl i ng 




WHEN manual mode_on 

P_manual_mode~on_handl ing 


WHEN power_off timeout 
set power_ol'f_ready 




WHEN manualjnode. on_timeout 
set raanual_mode 




WHEN buffer_full 

P_buf fer_full_handling 




ENDCASE 
ENDIF 
EHDLOOP 




END NETWORK_LAYER 





A 292 5153/3 
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2.1.1 P_LOOK_FOR_EMERGENCY 
P_look_for_emergency 

emergencyjsignal = FALSE 

WHILE NOT emergency_signal THEN 

CASE- MPAK. type 

WHEN SOS , SOSINFO , SOSACK , SOSCONREQ , SOSCONFAST 
eraergency_signal = TRUE 

WHEN OTHERWISE 

save_signal 
input_signal 



ENDWHILE 
END_P_look_for_emergency 
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P_KPAK_FROH_APP 

IP NOT buffer full flag THEN 
CASE next_state"" 

WEEN idle 

CASE MPAK. class 
WHEN PSUBCOM,PSOSCOM 

P_check format 

IP format = true THEN 

send MPAK_to_transmit to LINK 
next_state = LINKJ3USY 
ELSE 

send returned_MPAK_with_code: INCORRECT to APP 
ENDIP ~ 
WHEN CSOBCOM 

P_check_format 

IF format = true THEN 

P_check_and send_CSDBCOH 
ELSE ~ 

send returned_MPAK_with_code: INCORRECT to APP 
ENDIP 
WHEN DTESERV 

P_check_forraat 

IP format = true THEN 

P check and send DTESERV 
ELSE" ~ ~ 

send returned_MPAK_with_code: INCORRECT to APP 
ENDIP 
ENDCASE 
WEEN die_state 

• IP MPAK. class = DTESERV THEN 

P_check_format 

IP format = true THEN 

P check and_send DTESERV 
ELSE - ~ ~ 

send returned_MPAK_with_code : INCORRECT to APP 
ENDIP ~ ~ 

ELSE 

send r eturned_MPAK_with_code : NOT_SENT_DIE 
ENDIP 

WHEN wai t_f or_hook_of f _normal , 
wait_f or_hook_of f _f ast , 
wai t~for_hook_off_g roup 
IF MPAK. class = CSOBCOM THEN 
P_check_format 
IF format = true THEN 
CASE MPAK. type 
WHEN CONREA 

P_hook_of f _handli ng 
WHEN DISCON 

P hook_on_handling 
WHEN - OTHERWI SE 
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send returned MPAK with code : NOT_SENT_SPEECH 



IF MPAK. Class = PSOSCOM THEN 

save_signal 

make hook_on signal 

P_HOOK_ON_handling 

send returned MPAK with_code:NOT_SENT_SPEECH to APP 
ENDIF 
ENDIF 

WHEN sending conreq,sending_conrea,speech_nornial,speech_group 
IF MPAKTclass = CSUBCOM THEN 

P check_format 

IF format .= true THEN 
CASE MPAK. type 
WHEN D I SCON 

P_hook_on_.handling . 

•send returned MPAK with code:NOT_SENT_SPEECH 



IF MPAK. class = PSOSCOM THEN - 
CASE next state 

WHEN sendXng_conreq,sending_conrea 
save_signal 

send order_to_return_MPAK to LINK 
next_state = stop_sending 
WHEN speech_normal,speech_group 
save_signal 
make""hook on signal 
P HOOK ON~handling 



send returned_MPAK_with_code : NOT_SENT_SPEECH 



ENDIF 
I OTHERWISE 
save_signal 



CASE MPAK. class 
WHEN PSUBCOM, PSOSCOM 

P^heck^format 

IF format = true THEN 

send MPAK_to_transmit to LINK 
next_state = LINK_BDSY 

send returned MPAK with_code: INCORRECT to APP 
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send t etur ned_MPAK_wi tJi_code : NOT_SENT_BOFFER_POLL 



Exhibit 2, p. 428 



Cantel Mobitex- 



53/1056-A 296 5171/2 Ue 



F CHECK FORMAT 



F_check_format 

This routine checks and completes the format of this MPAK to be 

correct according to Rl-09 Appendix A. 

A correct MPAK will be returned with format = TRUE, 

An incorrect MPAK will be returned with format = FALSE. 

EHD_F_check_format 



2.2.2 P_CHECK_AND_SEND_DTESERV 



P_check_and send DTESERV 
CASE MPAK. type" 

WHEN LOGINREQ 

IF MPAK. type dependent in our flexlist THEN 

send returned_MPAK_with_code:PERSONAL_MAN_EXIST to APP 
ELSE 

IF more space in our flexlist 

MPAK. sender = MCO_MAN 

send MPAK to_transmit to LINK 

next_state = LINK BUSY 
ELSE ~ 

send returned MPAK_with_code:FLEXLIST_FULL 
ENDIF ~ 
END IF 

WHEN VICESOSRX,SOSRX 

IF MPAK. sender in our flexlist THEN 
send MPAK_to transmit to LINK 
next state =~LINK_BUSY 

ELSE 

send returned MPAK with code : PERSONAL MAN_NOT_EX 1ST to 
- - - ~ APP 

ENDIF 

VISES LOGOUT 

remove MPAK. sender from our flexlist 
MPAK.type_dependent = MCU_MAN 
send MPAK~to transmit to LINK 
next_state «~LINK_BUSY 

WHEN ACTIVE, INACTIVE 

send MPAK_to_transmit to LINK 
next_state= LINK_BUSY 

WHEN OTHERWISE 

send returned_MPAK_wifch_code: INCORRECT to APP 

END_P_check_and_sendJDTESERV 
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2.3 P_CHECK_AND_SEND_CStJBCOM 

P_check_and_send CSOBCOM 
CASE MPAK. type 

WHEN CONREQ , ADDCONREQ , SOSCONREQ , EXTCONREQ , 
CONFAST , ADDCONFAST , SOSCONFAST 
MPAK.line = 0 

MPAK. connection identity = next MPAK.connection_identity 
SPEECH_REG.part~here = MPAK. sender 
SPEECH_REG.other_part = MPAK. addressee 
SPEECH REG. line = MPAK.line 

SPEECH~REG.conn_id = MPAK.connection_identity 
send MPAK_to_transmit to LINK 
next_state =~sending_conreq 

WHEN DISCON 

send MPAK DISCON with 

MPAK. sender = SPEECH_REG.part_here 
... MPAK. addressee = SPEECH REG.other_part 
MPAK.line = SPEECH_REG . Tine 

MPAK.connection_identity = SPEECHJREG . conn_id 
send MPAK_to_transmit to LINK 
next_stati" =~sending_discon 

WHEN OTHERWISE 

ignore_signal 



END_P_cfaeck_and send CSOBCOM 
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2.3 P MPAK TO RETRANSMIT 



PJKPAK^tojretransmit 

CASE next_state 
WHEN idle 

CASE MPAK. class 



P_check_f ormat 

IP format = true THEN 

send MPAK to retransmit to LINK 

next_state =~LINK BtJS* 
ELSE 

send returned MPAK with code : INCORRECT to APP 
ENDIP _ _ _ 

WHEN OTHERWISE 

send returned MPAK with code : INCORRECT to APP 



WHEN die state 

send returned MPAK with code: NOT -SENT DIE 
WHEN wait_for_hook~off_normaX, ~ ~ 

wait~f or_hook~of f_f ast , 
wait_£or_hook_of f_group 
IF MPAK. class = PSOSCOM THEN 

save_signal 

make hook_on signal 

P_HOOK ON handling 
ELSE — ~ 

send returned MPAK with code: NOT SENT SPEECH to APP 
ENDIP - - - - - 

WHEN sending_conreq,sending_conrea,speech_normal, speech group 
IP MPAK. class = PSOSCOM THEN ~ 

CASE nextjstate 

WHEN sendXng_conreq,sending_conrea 
save signal 

send~order_to_return_MPAK to LINK 

next_state — = stop sending 
WHEN speech normal, speech group 

save_signal ~ 

make~hook on signal 

P_HOOK ON~handling 
ENDCASE ~ ~ 
ELSE 

send returned MPAK with code: NOT SENT SPEECH 
ENDIP ~ ~ 

WHEN OTHERWISE 

save signal 
ENDCASE ~ 
_P_MPAK_to_retransmit 
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2.4 P_REC_MPAK_FROM LINK 



P_REC_MPAK_FROM_L INK 

activated = TRUE 
CASE MPAK. class 
WHEN PSUBCOM,PSOSCOM 

IP F^get^jrecjnan = MCUJ1AN or in flexlist or in grouplist '. 
send MPAK received to APP 

ELSE 

P_unknown handling normal 
ENDIF . ~ 

WHEN CSUBCOM 

P_REC_MPAK CSUBCOM FROM LINK 
WHEN DTESERV ~ ~ 

IP F get recjnan = MCU MAN or in flexlist or in grouplist '. 
CASE MPAK. state . ~ 
WHEN ok,£rom_mail 

P_REC_MPAK DTESERV FROM LINK NORMAL 

WHEN OTHERWISE ~ 

CASE MPAK. type 

WHEN • LOGINREQ,SOSRX,VICESOSRX 

send MPAK_received to APP 

WHEN OTHERWISE 
ignore signal 



P unknown handling normal 
>IF 

;e 

end_p_rec_mpak from link 



2.4.1 P_ONKNOWN_HANDLING_NORMAL 



P_unknown_handling normal 
CASE next state ~ 
WHEN idle" 

set MPAK . UNKNOWN_F = 1 
send MPAK_to transmit to LINK 
next_state =~link busy 
WHEN die_scate ~ 

set MPAK. UNKNOWN F = 1 
send MPAK_to_transmit to LINK 
next state = sending during die 
WHEN OTHERWISE ' ~ 

save_signal 
ENDCASE" 
END_P_junknown_handling normal 
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2.4.2 P_REC_MPAK_DTESERV_FROH_LINK_NORMAL 

PJREC_MPAK_DTESERV PROM LINK NORMAL 
CASE MPAK . type ~ 
WHEN LOGINGRA 

Add personal subscription MAN to the flexlist 

send MPAK received to APP 
WHEN LOGINREF 

send MPAK_received to APP 
WHEN LOGOOTORD 

remove personal subscription MAN from the flexlist 

send MPAK_received to APP 
WHEN DIE 

IP next_state = idle or die state THEN 

next_state = die state ~ 

send die to APP ~ 
ELSE 

save signal 

. END 

WHEN LIVE 

IP next_state = idle or die state THEN 
next state = idle ~ 
send~live to APP 
ELSE 

save_signal 

WHEN GROUPLIST 

replace grouplist 

set grouplist_received flag 

send MPAK_received to APP 

send group list information to data link layer 
WHEN AREALIST 

send area list information to data link layer 
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tEN ROAMORD , FLEXREQ , INFOREQ , ESNREQ 
IF next_state = idle pr die scate THEN 
CASE MP AK. type 

WHEN ROAMORD make MPAK.type ROAM 
WHEN FLEXREQ make MPAK.type FLEXLIST 
WHEN INFOREQ make MPAK.type INFO 
""""I ESNREQ make MPAK.type ESNINFO 



send MPAK_to transmit to LINK 
CASE next_state 

WHEN idle next state = link busy 

WHEN die_state next~state = sendTng_during_die 



save signal 

ENDIF ~ 
WHEN FLEXLIST 

replace flexlist. 

send MPAK received to APP 
.WHEN TIME ~ 

send MPAK_received to APP 
WHEN OTHERWISE 

ignore_signal 
ENDCASE MPAK 
i_P_REC_MPAK_DTESERV FROM LINK NORMAL 
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2.4.2.1 F_GET_REC_MAN 



F_get_rec_man 

CASE MPAK. state 
WHEN ok,from_mail 

F_get_rec_man = MPAK. addressee 
WHEN OTHERWISE 

P_get_rec_raan = MPAK. sender 
ENDCASE MPAK. state 
END_P_g e t__r e c_man 



2.4.3 P_REC_MPAK_CSOBCOM_FROM_L INK 



P_REC_MPAK_CSDBCOM FROM_LINK 
CASE next_state 
WHEN idle~ 

P_REC_MPAK_CSUBCOM FROM LINK_IDLE 
WHEN link-busjvsending during~die, stop sending 

save signal ~ ~ ~ 

WHEN die_state 

P REC_MPAK CSDBCOM FROM LINK_DIE 
WHEN wait_for_hQok_off_normal7 
wait~for_hook_off fast, 
wai t_for_hook_off "group 

P_REC_MPAK_CSUBCOM FROM_LINK_WAIT 
WHEN speech normal, speecE_group 

P_REC~MPAK_CSCJBCOM FROM LINK_SPEECH 
WHEN sending_conreq "" — 

CASE MPAK. type 

WHEN CONREQ , AODCONREQ , SOSCONREQ , EXTCONREQ , 
CONFAST , ADDCONFAST , SOSCONFAST , CONORD 
save_signal 

send order_to_return_MPAK to LINK 
next state = stop_s ending 
WHEN OTHERWISE 

ignore signal 

ENDCASE MPAK 

WHEN sending_conrea 

IF MPAK. type DISCON THEN 
send MPAK_received to APP 
send order_to_return_MPAK to LINK 
next_state = stop sending 
ELSE 

ignore_signal 

send order to return_MPAK to LINK 

next state~= stop sending 
ENDIF ~ 
WHEN sending discon 
save_sTgnal 

send order_to_return_MPAK to LINK 
next state = stop sending 
ENDCASE ~ ~ 
END_P_REC_MPAK_CSDBCOM_FROM LINK 
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2.4.3.1 P_REC_MPAK_CSOBCOM_FROM 


_LINK_IDLE 


P HEC MPAK CSUBCOM FROM LINK IDLE 




CASE MPAK . type 




WHEN CONREQ , ADDCONREQ , SOSCONREQ , EXTCONHEQ 


CASE MPAK. state 




WHEN ok 




IP F get rec man = MCU HAN or in flexlist 


start 60 second timer 


for hook off 


SPEECH REG. part here 


= MPAK. addressee 


SPEECH REG. other part 


= MPAK. sender 


SPEECH REG. line = HPAK. line 


SPEECH_REG.conn_id = 


MPAK. connection identity 


send MPAK_received to 


APP 


nextjstate = wait_for 


_hook_of f _no r ma 1 


P unknown .handling csubcora 


ENDIF 




WHEN OTHERWISE 




.. send speech off to LINK 


ENDCASE MPAK. state 




WHEN CONFAST , ADDCONFAST , SOSCONFAST 


CASE HPAK. sea te 




WHEN ok 




IF F_get_rec_man = MCD_MAN or in flexlist 


start~10 second timer for hook off 


SPEECH_REG . par tjiere 


= MPAK. addressee 


SPEECH REG. other Dart 


= MPAK. sender 


SPEECH REG. line = MPAK. line 


SPEECH_REG.conn_id = 


MPAK. connection identity 


send MPAK_received to 


APP 


next state = wait for 


hook off fast 


send speech on to LINK 


ELSE 




P unknown handling csubcom 


ENDIF 




WHEN OTHERWISE 




send speech off to LINK 


ENDCASE MPAK. state 
WHEN CONORD 




CASE MPAK. state 




WHEN ok 




IF F get rec man in grouplist 


start 60 second timer 


for hook off 


send MPAK_received to 


APP 


next state = wait for 


hook off group 


. send speech on to LINK 


ELSE 




send speech_off to LINK 


WHEN OTHERWISE 




send speech off to LINK 


ENDCASE MPAK. state 





A :!!>2 31533 
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WHEN OTHERWISE 

send speech off to LINK 
ENDCASE MPAK 
aro_P_REC_HPAK CSDBCOH PROM LINK IDLE 



2.4.3.2 P_UNKNOWN_HANDLING CSOBCOM 



Pjunknown handling csubcom 
send~speech_on to LINK 
make MPAK DISCON with 

MPAK. sender = received_MPAK. addressee 
MPAK. addressee = received_MPAK. sender 
MPAK. line = receiyed_MPAK.line 
MPAK.connection_identity = 

received MPAK. connection identity 

MPAK . UNKNOWN_F= 1 
send MPAK_to_transmit to LINK 
next_state , ^"sending^discon 
END_Pjunknown_handling_csubcom 



2.4.3.3 P_REC_MPAK_CSOBCOM_FROM_LINK_DIE 



P_REC_MPAK CSOBCOM FROM LINK DIE 
. CASE MPAK. type ~ 
WHEN CONREQ , ADDCONREQ , SOSCONREQ , EXTCONREQ , 
CONPAST , ADDCONFAST , SOSCONFAST 
CASE MPAK. state 
WHEN ok 

send speech_on to LINK 
make MPAK DISCON with 

MPAK. sender = received_MPAK. addressee 
MPAK. addressee = received MPAK. sender 
MPAK. line = received_MPAK7line 
MPAK.connection_identity = 

received MPAK. connection identity 
IF F_get_rec man = MCU MAN~or in flexlist ~ 

send MPAK~to transmit to LINK 
ELSE ~ ~ 

set UNKNOWN_F = 1 in MPAK DISCON 
send MPAK to transmit to LINK 
ENDIF ~ ~ 

next_state = sending_during_die 
WHEN- OTHERWISE 

•send speech_off to LINK 
ENDCASE MPAK. state 
WHEN OTHERWISE 

send speech off to LINK 
END_P_HEC_MPAK_CSDBCOM~FROM_LINK DIE 
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P_REC_MPAK_CSOBCOM FROM LINK WAIT 



P_REC_MPAK_CSOBCOM FROM LINK WAIT 
CASE MPAK.type - - - 
WHEN DISCON 

reset hook_off timeout 

send speech off to LINK 

send MPAK_riceived to APP 

next_state = idle 
«HEN CONORD 

ignore signal 

IF nextjstate < > wait_for_hook_of fjgroup THEN 
reset hook. off timeout 
send speech_off to LINK 
next state = idle 
make~MPAK DISCON 
send MPAK received to APP 

ENDIF 



ETO_PJffiC_OTAKj:saBcbjrFROM_LINK_HAlT 
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2.4.3.5 P_REC_MPAK_CSUBCOM_FROM_LINK_SPEECH 

P_REC_MPAK CSDBCOM FROM LINK SPEECH 
CASE MPAK. type ~ 

WHEN CONREQ , ADDCONREQ , SOSCONREQ , EXTCONREQ , 
CONFAST , ADDCONFAST , SOSCONFAST 
CASE MPAK. state 

WHEN no_transfer, illegal, congest, error , busy 

send speech_off to LINK 

send MPAK_received to APP 

next_stati" = idle 
WHEN OTHERWISE 

ignore signal 

make MPAK DISCON 

send MPAKjreceived to APP 

send speech_off to LINK 

next_state- = idle 
ENDCASE MPAK. state 
WHEN DISCON 

send MPAK received to APP 

send speech_off to LINK 

next state = idle 
WHEN CONORD ~ 

ignore_signal 

IF next state < > speech group THEN 
make MPAK DISCON ~ 
send MPAK_received to APP 
send speech_off to LINK 
next_state = idle 

END IF 



ignore signal 

make MPAK DISCON 

send MPAK_received to APP 

send speech off to LINK 

next state = idle 



END_P_REC_MPAK_CSDBCOM FROM LINK SPEECH 
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2.5 P_MP AK_TRANSMI TTED 

F_MPAK_TRANSMITTED 
activated = TRUE 
CASE MPAK. class 
WHEN PSOBCOM,?SOSCOM,DTESERV 
CASE next_state 
WHEN link_busy 

next_state = idle 
WHEN sending during die 
next state = die~state 



IP MPAK . UNKNOWN F = 0 THEN 

IP MPAK. class = DTESERV THEN 
CASE MPAK. type 

WHEN LOGINREQ,SOSRX,VICESOSRX 

send returned MPAK with_code:SENT to APP 
WHEN INACT-IVE 

IP power_of f THEN 

set power off ready 

ENDIP ~. 

IP manual_mode_on received THEN 

set manual mode 
ENDIP 



ELSE 

send returned_MPAK_with_code:SENT to APP 
IF (MPAK. class = PSOBCOM) AND {buf f er_full_f lag) 
• malce MPAK INACTIVE 
send MPAK to_transmit to LINK 
next_state = link busy 
ENDIP MPAK. class 
ENDIP MPAK. class 
ENDIP MPAK. UNKNOWN F 
I CSUBCOM 

CASE MPAK. type 

WHEN CONREQ , ADDCONREQ , SOSCONREQ , EXTCONREQ , 

CONFAST , ADDCONFAST , SOSCONFAST 

send speech on to LINK 

send returned_MPAK_with_code:SENT to APP 
next_state » speecE_normal 



send speech on to LINK 

send returned MPAK with code: SENT to APP 



send speech off to LINK 
send returned MPAK_with_codes SENT t o AP P 
IP next_state~= sending_during_die THEN 
next_state = die_state 

ELSE 

next state =• idle 



! MPAK 
ENDCASE MPAK. Class 
END_P HPAK TRANSMITTED 
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2 . 6 P_MPAK_NOT_TRANSMITTED 




P MPAK HOT TRANSMITTED 




CASE MPAK. class 




WHEN PSOBCOM r PSOSCOM,DTESERV 




CASE next state 




WHEN link_busy 




next state = idle 




WEEN sending during die 




next state « die state . 


WHEN stop_sending 




next state = idle 




ENDCASE . " 




IF HP AK. UNKNOWN F = 0 TH 


EN 


IF MP AK. class = DTESERV THEN 


CASE MP AK. type 




WHEN LOGINR£Q,SOSRX,VICESOSRX 


send returned MPAK with code : NOT SENT to APP 


WHEN INACTIVE 




IF power_off 


THEN 


set power 


_off_ready 


IF manual_mode_on received THEN 


set manual mode 


END IF 
ENDCASE 




ELSE 

send returned MPAK 


_with_CodesNOT_SENT to APP 


ENDIF MPAK. class" 




ENDIF MPAK . UNKNOWN F 




WHEN CSUBCOM 




CASE MPAK. type 




WHEN CONPJSQ , ADDCONREQ , SOSCONR 


EQ,EXTCONREQ, 


CONFAST , ADDCONFAST , SOSCONFAST 


IF next state = sending_conreq THEN 


send speech off to LINK 


ENDIF 




next state ■ idle 




send speech off to LINK 


next state = idle 




WHEN DISCON 




send speech_off to LINK 


IF next state = sending_during_die THEN 


next_state = die_state 
ELSE ~ ~ 


next_scate = idle 


ENDCASE MPAK 




send returned MPAK with code: NOT SENT to APP 


ENDCASE MPAK. class 




END_P_MF AK_NOT_TRANSMI TTED 
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2.7 P_HOOK_ON_HANDLING 




PJH0OK_0N_handling 




CASE next_state 




WHEN wait_for_hook_off_normal, 




wait~f or_hook_of f _f ast , 




wait~for hook~of f~grouD 




reset hook off timeout 


P_t imeout_handli ng 




WHEN sending conreq, sending conrea 


save_signal 




send order to return 


MPAK to LINK 


next_state = stop_sending 


WHEN speech normal 




make MPAK .DISCON with 




MPAK. sender = S 


PEECH REG. part here 


MPAK. addressee 


= SPEECH REG. other part 


MPAK. line = SPEECH REG, line 


MPAK. connection identity = SPEECH REG. conn id 


send MPAK to transmit 


to LINK 


next_state = sending_discon 


WHEN speech group 




send speech off to LINK 


next_state = idle 




WHEN idle 




IF line connection request received THEN 


make MPAK DISCON with 


MPAK. sender = S 


PEECH REG. part here 


MPAK. addressee 


= SPEECH REG.other_part 


MPAK. line = SPE 


ECH REG. line 


MPAK. connection. identity = SPEECH_REG.conn_id 


send MPAK_to_transmi't to LINK 


next state = sending discon 


ELSE 




ignore signal 




ENDIF 




WHEN OTHERWISE 




ignore signal 




ENDCASE next_state 




END P HOOK ONJhandling 
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2 . 8 P_TIMEOUT_HANDLING 






P timeout handling 
CASE next state 

WHEN wait_f or_hook_of f_normal , wait_f or_hook_of f _f ast 
send speech on ta LINK ~ 
make MPAK DISCON with 

MPAK. sender = SPEECH REG. part here 
MPAK. addressee = SPEECH REG.other_part 
MPAK. line = SPEECH_REG. line 

MPAK. connection identity = SPEECH REG. conn id 
send MPAK_to_transrait to LINK 
next_state = sending_discon 




WHEN wait_for_hook_off group 
send speech off to LINK 
next_state = idle 






WHEN OTHERWISE 

ignore signal 
EHDCASE next_state 
END_P_timeout_handling 






2 . 9 P_HOOK_OFP_HANDLING 






P_HOOK_OFFJiandl ing 
CASE next_state 
WHEN wait for hook off normal 
reset hook off timeout 
make MPAK CONREA with 

MPAK. sender = SPEECH REG. part here 
MPAK. addressee = SPEECH REG. other part 
MPAK. line = SPEECH REG. line 

MPAK. connection identity = SPEECH REG. conn id 
send MPAK_to_transrait to LINK 
next_state =~sending_conrea 




WHEN wait_for_hook off fast 
reset hook_of"f timeout 
next_state = speech_normal 






WHEN wait_for hook off group 
reset hook_off timeout 
next_state = speech_group 






WHEN OTHERWISE 

ignore signal 
ENDCASE next state 










ENl>_P_HO0K_0PF_handling 




fepcoo 
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2.10 P_ROAMING HANDLING 



P_roaming_handling 

IP next_state « idle or die_state TE 
IP grouplist received flag THEN 

make MPAK ROAM 
ELSE 

make MPAK BORN 
END IF 

send MPAK_to transmit to LINK 
CASE next state 
WHEN idle - 

next_state = link busy 
WHEN die_state 

next state = sending durinq die 
ENDCASE" 
ELSE 

save signal 

ENDIF 

END_P_roaraing_handling 
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2 . 11 P J^CTIVATION_HANDLING 




P activation handling 

IP HOT buffer_full_flag THEN 
activated ="~FALSE 

start activation timer with 'active_delay_power_on' 


END_P_activation_handling 




2 . 12 P_ACT I VAT I ON_HANDL ING_L I NK 




P activation handling link 

IP NOT buffer full flag THEN 
activated = FALSE - 

start activation timer with 'active_delay_lost_contact' 


END_P_act iva t ion_handli ng_link 




2.13 P_ACTIVATION_TIMEOOT_HANDLING 


P_activation_timeout handling 

IP next_state = -i<Tle or die state THEN 
IF NOT activated THEN ~ 
make MPAK ACTIVE 
. send MPAK_to_transmit to LINK 
CASE next_state 
WHEN idle"" 

' next_state = link busy 
WHEN die_state ~ 

next state = sending during_die 
ENDCASE 


ENOIF 
ELSE 

save_signal 

ENDIF 

END P activation_timeout handling 
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2.14 P_POWER_OFF HANDLING 



P_power_off_handling 
power_off received 
start - power_o£f timer 
CASE next_state 
WHEN idle 

make- MPAK INACTIVE 

send MPAK_to transmit to LINK 

next_state =~link_busy 
WHEN die_state ~ 

make MPAK INACTIVE 

send MPAK_to_transmit to LINK 

next_state = sending during_die 
WHEN speech_normal,speech_group,wait_Eor_hook_of f_normal» 
wait_for_hook_of f_fast,wait_for~hook_of f_group, 
sendTng_CDnrea, sending jdiscon,sending_conreq 

disconnect the speech (according to current state) 

make MPAK INACTIVE 

send MPAK_to_transmit to. LINK. 

next_state = link busy 
WHEN OTHERWISE ' 

save signal 
ENDCASE - 
END_Pjpower_off_handling 



2.15 P_MANO AL_MODE_ON_HANDL ING 



P_manual_mode_on_handling 
raanual_mode_on received 
start manual_mode_on_timer 
CASE next state ~ ~ 
WHEN idle 

make MPAK INACTIVE 

send MPAK_to_transrait to LINK 

next_state =~link_busy 
WHEN die state ~ 

make MPAK INACTIVE 

send MPAK_to_transrait to LINK 

next_state = sending_during_die 
WHEN speech normal, speech group, wait_for_hook_off_norraal, 
wait_for_hook_off_fai"t,wait_for~hook_off "group, 
sending_conr ea , sending_discon , sending_conr eq 

disconnect the speech (according to current state) 

make MPAK INACTIVE 

send MPAK_to_transmit to LINK 

next_.state =~"link_busy 

WHEN OTHERWISE 

save_signal 
ENDCASE 



END_P_manual_mode_on_handl i ng 
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2.16 P BUFFER FULL HANDLING 



P_buf f er_f ull_handling 
CASE next_state 
WHEN idle 

make MPAK INACTIVE 

send MPAK_to_transmit to LINK 

next_state =~link_busy 
WHEN die state 

make MPAK INACTIVE 

send MPAK_to_transmit to LINK 

next_state = sending_during_die 
WHEN speech_normal,speechjgroup,wait for_hook_of f_normal, 
wait T for_hook_off_fast,wait_for~hook_off_group, 
sendTng_conr ea , sending_discon , sending_conr eq 

disconnect the speech (according to current state) 

make MPAK INACTIVE •• 

send MPAK_to_transmit to LINK 

next_state = link busy 
WHEN OTHERWISE ~ 

save_signal 
ENDCASE 



send buffer full to APP 
set buffer_full_flag 

END_P_buffer_full_handling 
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3 MOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 

Rl-06, 4, 6 
Rl-09, 7, 18 



Below are the reference designations listed. 



Reference Section 

Rl-01 •• Arrangement of the documents 

Rl-02 MOBITEX System description 

Rl-03 General description of terminals 

Rl-04 — Terminology 

Rl-05 References 

Rl-05. Network operator information 

Rl-08 Application layer 

Rl-09 ' Network layer 

Rl-11 Interface requirements, fixed terminals 

Rl-12 Other requirements, fixed terminals 

Rl-15 Link layer, mobile terminals 

Rl-17 Physical layer , mobile terminals 

Rl-18 Radio equipment, mobile terminals 

Rl-19 Other interfaces, mobile terminals 

Rl-20 Other requirements, mobile terminals 
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This document is a specification of the interface for a 
fixed terminal with HDLC interface, connected to the 
MOBITEX network. 
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1 INTRODUCTION 



1 . 1 GENERAL 



The designation "terminal" for a fixed terminal in the 
MOBITEX network corresponds to DTE in CCITT recommenda- 
tions and secondary station in HDLC. 

CCITT recommendation X.21 bis is used at the physical 
layer and HDLC is used at the link layer. The network 
layer consists -of MPAK's according to reference Rl-09. 
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2 PHYSICAL LAYER 



2.1 GENERAL 

Connection is in accordance with CCITT recommendation X.21 
bis. 



2.2 BITRATE 

For information about permitted bitrate transmission 
rates , please refer to reference Rl-06. 
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3 LINK LAYER 



3 . 1 GENERAL 



The design of the link layer follows ISO standards "High 
level data link control" (HDLC) . See ISO 3309-1984, ISO 
4335-1984 and ISO 7809-1984 for reference. 



3.2 



SOB-SET OF HDLC 



HDLC is a comprehensive catalogue of standards for link 
control. The UNC 12 class, i.e. "Unbalanced operation, 
normal response mode" with added test function, of 
procedure is used for the link layer. 

The MOBITEX network is the primary station and the fixed 
terminal is the secondary station. 



3.2.1 
3.2.1.1 



Clarification 

Commands and responses 



Command from 
network 


Response from 
fixed terminal 


I 


I 


RR 
RNR 


RR 
RNR 


SNRM 


DA 


DISC 


DM 


TEST 


FRMR 
TEST 



3.2.1.2 Frame size 

A frame can be up to 566 octets including start and stop 
flag. This will allow 560 octets in an information field 
in an I frame. 
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3.2.1.3 ' The use of the address field 

The address field comorises one octet. The address in the 
address field shall be adjustable. The factory set address 
shall be 11000000 {bit 1...8). 

Address 11111111 is defined as the all-station address and 
thus all receiving data stations shall accept and action 
the associated frame. If the P bit is set in such a frame, 
the terminal shall reply with its own address as reply 
address . 



3.2.1.4 FRMR responses 

The information field in an FRMR response shall be padded 
with zeros so .the length will be 3 octets. 

3.2.1.5 TEST -frames 

. TEST frames can contain an information field. The maximum 
length of that field is the same as' for I-frames. 

TEST frames can be' transmitted and received both in NRM 
and NDM. 
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3.3 OPERATING MODES FOR THE LINK LAYER 

The link layer shall be able to assume the following 
modes : 

o Normal resonse mode (NRM) according to ISO 4335 item 
5.1.1. 

o Normal disconnected mode (NDH) according to ISO 4335' 
items 5.2 and 5.2.1. 

A terminal's capacity in NDH is limited to: 

- accepting the mode setting commands (SNRM or DISC) 

- accepting and responding to a test command 

- transmitting DM or TEST at a respond opportunity 

A terminal- may only -change - to NRM from NDM by accepting an 
SNRM command from the network. 

A terminal can change from NRM to NDM by accepting a DISC 
command from the network or through manual restart of the 
link control. NDM shall be the initial mode when power is 
switched on or when restarting the terminal. 
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3.4 CONNECTION AND DISCONNECTION PROCEDURE 

The link is connected in accordance with ISO 7809 item 
3.4.1.1. The network transmits SNRM to the terminal. If 
there is no reply, the SNRM is retransmitted until an UA 
reply is received. 

Normal disconnection of the link is in accordance with ISO 
7808, item 3.4.1.2. If there is no reply from the 
terminal, DISC is retransmitted. This is repeated no more 
than 10 times or until an UA reply is. received. The link 
is then assumed to be disconnected and the connection at 
the lower level can be broken. 

If there are no frames to send, the link layer shall send 
flags continuosly as soon as the physical layer is in data 
transmission mode. 



3.5 TIME-OUT 

When the terminal receives a correct frame with the P bit 
set to "1" (one), the reply shall commence within 50 ms. 
The time is calculated from when the last bit of the 
command's closing flag is received until the first bit of 
the response is transmitted. 

If several frames are transmitted in sequence, the time 
between them shall not exceed 50 ms. This time is 
calculated from the last bit of a frame's closing flag to 
the first bit of the next frame's opening flag. 

The terminal has no time-out function for recovery in the 
event of a link fault. The terminal however may have time- 
out function to inform the operator about a link fault. 
The time-out may not be less than 45s in NRM and 120 s in 
NDM. 



3.6 RECOVERY FROM FAULT CONDITION 

All recovery from a fault condition is carried out by the 
network. The terminal is first ordered to NDM and then to 
NRM. 
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4 MOB I TEX TERMINAL •SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 



Below are the reference designations listed. 



Reference Section 

Rl-01 -- Arrangement of the documents 

Rl-02 MOBITEX System description 

Rl-03 General description of terminals 

Rl-04 Terminology 

Rl-05 References 

Rl-06 Network operator information 

Rl-08 Application layer 

Rl-09 Network layer 

Rl-11 Interface requirements, fixed terminals 

Rl-12 Other requirements, fixed terminals 

Rl-16 Link layer, mobile terminals 

Rl-17 Physical layer, mobile terminals 

Rl-18 Radio equipment, mobile terminals 

Rl-19 Other interfaces, mobile terminals 

Rl-20 Other requirements, mobile terminals 



The following external references are made in this 
document : 

CCITT recommendations series X, 1984 Edition (Red 
Book) X.21 bis 

ISO-standards: 

ISO 3309-1984(E) 
ISO 4335-1984(E) 
ISO 7809-1984(E) 
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ABSTRACT 

This document is a specification of the interface for a 
fixed terminal with X.25 interface, connected to the 
MOBITEX network. 
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1 INTRODUCTION 



1.1 GENERAL 

The designation 'terminal' for a fixed terminal in the 
MOBITEX network corresponds to DTE in CCITT recommenda- 
tions for X.25 packet layer and link layer. 

Connection of a terminal with X.25-interface can be done 
directly to the MOBITEX network or through an X.25 
network. 



CCITT recommendation X.21 bis is used at the physical 
layer, LAPB is used at the link layer and X.25 is used at 
the packet layer. 

The user data in X.25 packet layer should contain MFAKs as 
described in reference Rl-09. 
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2 PHYSICAL LAYER 



2 . 1 GENERAL 



Connection is in accordance with CCITT recommendation 
X.21 bis. 



2.2 . BITRATE 

For information about permitted bitrate transmission 
rates, please refer to reference Rl-06. 
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3 LINK LAYER 

The design of the link layer follows LAPB, Link Access 
Procedure Balanced, according to CCITT recommendation 
X.25. 

The extended format modulo 128 is not supported. 
The multilink procedure MLP is not supported. 
Timeout period is Tl=3 seconds. 
Maximum number of outstanding frames are K=7. 
Number of retransmission attempts are N2=10. 
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4 PACKET LAYER 



The design of the packet layer follows CCITT 
recommendation X.25 for DTE with the following 
restrictions: 

When the terminal is using direct connection there is only 
one logical channel. The logical channel group number 
should be zero and the .logical channel number should be 
one . 

When connection is made through an X.25 network, maximum 
number of logical channels are 8. 

The delivery-bit should be set to zero in all data 
packets. 

The qualifier-bit is ignored by the MOBITEX network. 

The sequence numbering scheme of the data packets is 
performed modulo 8. 

The standard default value for the window size is two 
packets. It is possible to change the default window size 
to 1, 3, 4, 5, 6 or 7 packets. 

The standard default value for the packet size is 128 
octets. It is possible to change the default packet size 
to 32, 64, 256, or 512 octets. 

Interrupt, reject and registration packets are not 
supported. 

The following facilities are supported: 

- Plow control parameter negotiation. 

- Non standard default packet size. 

- Non standard default window size. 

- Reverse charging. (See note 1.) 

- Reverse charging acceptance. (See note 1.) 

A connected terminal can communicate with MOBITEX through 
a permanent virtual circuit (PVC) or through a virtual 
circuit (VC). 
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If no packets, in either direction, has been transmitted 
on the logical channel during X (default 4 and possible to 
change) minutes a virtual call will be cleared by the 
MOBITEX network if the connection is VC. 

Note 1 : Only used when connected through an X.25 network. 

The packet call request/incoming call and call accepted/ 
call connected should contain both calling DTE address and 
called DTE address (optional in CCITT X.25). 
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4.1 Diagnostic codes 

Coding of the restarting cause field and the diagnostic 
code field in a restart packet, used by the mobitex 
network and the connected terminal. 

c ause diagn. explanation 

00 local procedure error 

17 invalid packet type for state rl 

52 time expired for restart indication 

07 network operational 



Coding of the clearing cause field and the diagnostic code 
field in a clear packet, used by the MOBITEX network and 
the connected .terminal. 



cause diagn. . explanation 

0 dte originated 
0 dte clearing 

01 number busy 

72 call collision 

03 invalid facility request 

65 facility code not allowed 

66 facility parameter not allowed 



19 local procedure error' 

20 invalid packet type for state pi 

21 invalid packet type for state p2 

22 invalid packet type for state p3 
24 invalid packet type for state p4 
26 invalid packet type for state p6 
33 unidentifiable packet 

38 packet too short 

41 restart with nonzero in bits 1-4 in octet 
1 or nonzero in bits 1-8 in octet 2 

49 time expired for incoming call 

50 time expired for clear indication 

51 time expired for reset indication 

67 invalid called address 

68 invalid calling address 

69 invalid facility length 
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Coding of the resetting cause field and the diagnostic 
code field in a reset packet, used by the MOBITEX network 
and the connected terminal. 

cause diaqn. explanation 

05 local procedure error 

01 invalid p(s) 

02 invalid p(r) 

27 invalid packet type for state dl 

32 packet type not allowed (registration or 

interrupt packet) 
35 invalid packet type oh pvc channel 

37 reject packet not subscribed 

41 restart with nonzero in bits 1-4 in octet 

1 or nonzero in bits 1-8 in octet 2 
51 time expired for reset indication 



Coding of the diagnostic code field in a diagnostic 
packet, used by the MOBITEX network and the connected 
terminal. 

explanation 

packet on unassigned logical channel 
packet too short 

invalid general format identifier 
time expired for clear indication 
time expired for reset indication 
time expired for restart indication 



Exhibit 2, p. 468 





Cantel Mobitex~ 


1056 - A 296 5491 Ue 


T99 0^0 2-26 "£ |*MTS11X25.1 



5 MOBITEX NETWORK LAYER 

The MPAK should be placed in the user data field in one or 
more X.25 data packets. An MPAK should be handled as a' 
complete packet sequence, according to CCITT's X.25 
recommendation # 4.3.5. 

Note: The D-bit should always be set to zero in 
communication with the MOBITEX network. 

If the transmission of an MPAK is interrupted by a 
restart, reset or clear procedure the whole MPAK should be 
retransmitted. 
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6 MOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 

Rl-06, 4 
Rl-09, 3 



Below are the reference designations listed. 



Reference Section 

Rl-01 . Arrangement of the documents 

Rl-02 MOBITEX System description 

Rl-03 General description of terminals 

Rl-04 Terminology 

Rl-05 References 

Rl-06 Network operator information 

Rl-08 Application layer 

Rl-09 ■ Network layer 

Rl-11 Interface requirements, fixed terminals 

Rl-12 Other requirements, fixed terminals 

Rl-16 Link layer, mobile terminals 

Rl-17 Physical layer, mobile terminals 

Rl-18 Radio equipment, mobile terminals 

Rl-19 Other interfaces, mobile terminals 

Rl-20 Other requirements, mobile terminals 



The following external references are made in this 
document : 

CCITT recommendations series X, 1984 edition (Red. 
book) X.25 and X.21 bis 
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This document is a specification of the interface for a 
fixed terminal with binary synchronous communication (BSC) 
interface, connected to the MOBITEX network. 
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1 INTRODUCTION 



1 . 1 GENERAL 

The designation "terminal" for a fixed terminal in the 
MOBITEX network corresponds to DTE in CCITT recommenda- 
tions. 

CCITT recommendation X.21 bis is used at the physical 
layer. The link layer is IBM's BSC (binary synchronous 
communication) , see chapter 2. 

The network layer is a character oriented MFAK (BSCPAK), 
see chapter 4. 
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2 PHYSICAL LAYER 

2.1 GENERAL 

Connection is in accordance with CCITT recommendation X.21 
bis. 

2.2 BITRATE 

For information about permitted bitrate transmission 
rates, please refer to reference Rl-06. 




Exhibit 2, p. 474 



Cartel Mobitex- 



1056 - ft 296 5490 Ue 

199 0-0 2-2 S '"c l-MTSllBSC.l 



3 LINK LAYER 

The design of the link layer follows IBM General 
Information - Binary Synchronous communications, GA27-3004 
with the following restrictions: 

Point-to-point connection is used. The Mobitex network has 
a retry timeout of 3 seconds. 

ITB and RVI will be handled by the Mobitex network when, 
received, but is never transmitted. 

Transparent mode is not handled by the Mobitex network. 

SOH can be received but the content of the header is not 
interpreted. SOH is never transmitted. 

The Mobitex network retransmits max 15 times. 
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4 NETWORK LAYER 

The network layer use BSCPAK. A BSCPAK is a character- 
oriented MPAKr MPAKs are bit-oriented and are described in 
reference Rl-09. 

BSCPAK is EBCDIC-coded , see chapter 6. 

All MPAK, except MPAK DATA, HPDATA and EXTPAK can be 
translated to BSCPAK. 

Sendlist is not handled. 

All numeric fields are right adjusted with preceding 
zeroes. 

BSCPAK shall be handled in the same way as corresponding 
MPAK. 

Maximum length for a BSCPAK is 548 octets (BSCPAK TEXT 
without sendlist) . 

A BSCPAK may be divided into several blocks, each of which 
ends with ETB except the last one which ends with ETX. 

The content of the text field in a BSC-block is a BSCPAK 
(or part of BSCPAK) in either direction, to or from the 
Mobitex network. 

STX precedes and ETX ends a BSCPAK. 



Cartel Mobitex 
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5 SPECIFICATION OF BSCPAK 

BSCPAK shall be handled, according to reference Rl-09, in 
the same way as corresponding MPAK. Below is a description 
of the translation between bit-oriented MPAK and the 
character oriented BSCPAK. 

All BSCPAKs consist of one BSCPAK header and one part with 
typedependent components . 

All characters in a BSCPAK shall be in EBCDIC code. 



BSCPAK, COMMON COMPONENTS 



BSCPAK-field . 


octet 


comment 


sender 


1- 8 


only digits 


adressee 


9-16 


only digits 


class 


.17 • 


only digits 


extern F 


18 


0 or 1 


type 


19-20 


only digits 


mailbox F 


21 


0 or 1 


digital~F 


22 


0 or 1 


sendlist_F 


23 


0 


unknown_F 


24 


0 or 1 (0 from Mobitex) 


reserve_F 


25 


0 


traf state 


26 


0 ... 7 (0 to Mobitex) 



Length 26 octets. 



Octet 1 will be transmitted first. 
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5.2 BSCPAK COMPONENTS 

The following components ate described in this chapter: 

TEXT 

STATUS 

SOSINFO 

SOSACK 

CONREQ 

SOSCONREQ 

ADDCONREQ 

CONGRA 

CONORD 

CONREA 

DISCON 

EXTCONREQ 

CLOOPON 

CLOOPOFF 

LOGINREQ 

LOGINGRA 

LOGINREF 

LOGOUT 

LOGOOTORD 

ACTIVE 

INACTIVE " 

DIE 

LIVE 

VICESOSRX 

SOSRX 

GRODPLIST 

PLEXREQ 

FLEXLIST 

TIME 
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* TEXT without adress 


list: 




BSCPAK-field 


octet 


comment 


bscpak-header 

time 

text 


1-26 
27-36 
37- 


decimal digits (YYMMDDHHMM) 
all characters included in 
Mobitex textcode (EBCDIC- 
coded), 1-512 characters 


Length 37-548 octets. 






* STATUS without adress list: 




BSCPAK-field 


octet 


comment 


bscpak-header 
time 

status code 


1-26 
27-36 
37-39 


decimal digits (YYMMDDHHMM) 
only digits 000 ... 255 



Length 39 octets. 



BSCPAK-field 



bscpak-header 
time 

static emergency 
information 



octet comment 



Length 36-548 octets. 



27-36 decimal digits (YYMMDDHHMM) 

37- all characters included in 
Mobitex textcode (EBCDIC- 
coded), 0-256 characters 

'37- all characters' included in 
Mobitex textcode (EBCDIC- 
coded), 0-256 characters 



* SOSACK 
BSCPAK-field 



bscpak-header 
time 



octet comment 



27-36 decimal digits" (YYMMDDHHMM) 



emergency 

acknowledgement status 37-39 decimal digits 000.. 255 
Length 39 octets. 
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* CONREQ 
BSCPAK-field 



octet comment 



bscpak-header 
line number 



connection identity 
Length 32 octets. 



1-26 

27-29 decimal digits 000.. 255 

(000 from terminal) 
30-32 decimal digits 000.. 255 



* SOSCONREQ 

BSCPAK-field octet comment 

bscpak-header 1-26 ~~ 7~_ 

line number 27-29 decimal digits 000.. 255 

(000 from terminal) 

connection identity 30-32 decimal digits 000.. 255 

Length 32 octets. 



• ADDCONREQ 
BSCPAK-field 



octet comment 



bscpak-header 
line number 



1-26 
27-29 



connection identity 30-32 
additional information 33-52 



Length 52 octets. 



decimal digits 000.. 255 
(000 from terminal) 
decimal digits 000.. 255. 
all characters included in 
Mobitex textcode (EBCDIC- 
coded) 



* CONGRA 

BSCPAK-field octet comment 

bscpak-header 1-26 \7 . ^ „„„ - =c 

line number 27-29 decimal digits 000.. 255 

(000 from terminal) 

connection identity 30-32 decimal digits 000.. 255 

Length 32 octets. 
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BSCPAK-field 



bscpak-header 
line number 



connection identity 
Length 32 octets. 



octet comment 



1-26 

27-29 decimal digits 000. .255 

(000 from terminal} 
30-32 decimal digits 000. .255 



BSCPAK-field octet comment ■ 

bscpak-header 1-26 

line number 27-29 decimal digits 000.. 255 

(000 from terminal) 
connection identity 30-32 decimal digits 00.0.. 255 

Length 32 octets. 



BSCPAK-field octet comment „ 

bscpak-header 1-26 '• 

line number 27-29 decimal, digits 000.. 255 

(000 from terminal) 
connection identity 30-32 decimal digits 000.. 255 

Length 32 octets. 



octet comment 



* EXTCONREQ 

BSCPAK-field 

bscpak-header 1-26 

line number 27-29 

connection identity 30-32 

subscr. no. in ext. 

network 33-52 

Length 52 octets. 



decimal digits 000.. 255 
(000 from terminal) 
decimal digits 000.. 255 

decimal digits 



* CLOOPON 

BSCPAK-field 

bscpak-header 
line number 

Length 29 octets. 



decimal digits 000.. 255 
(000 from terminal) 
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* CLOOPOFF 








BSCPAK-field 


octet 


comment 


bscpak-header 


1 
27 


-26 
-29 


decimal digits 000. .255 
(000 from terminal) 


• Length 29 octets. 








* LOGINREQ 








BSCPAK-field 


octet 


comment 


bscpak-header 
HAN 

password 


1 
27 
35 


-26 
-34 
-42 


only decimal digits 
all characters included in 
Hobitex textcode { EBCDIC- 
coded) 


Length 42 octets. 








* LOG INGRA 








BSCPAK-field 


octet 


comment 


bscoak-header 
HAN 


1-26 
27-34 


only decimal digits - 


Length 34 octets. 








* LOGINREF 








BSCPAK-field 


octet 


comment 


bscpak-headec 
HAN 


1 
27 


-26 
-34 


• only decimal digits 


Length 34 octets. 








* LOGOUT 








BSCPAK-field 


octet 


comment 


bscpak-headec 
HAN 


1 
27 


-26 
-34 


only decimal digits 


Length 34 octets. 
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* LOGOOTORD 

BSCPAK-field octet comment 



bscpak-header 
HAN 


1-26 
27-34 


only decimal digits 


Length 34 octets. 






* ACTIVE 






BSCPAK-field 


octet 


comment 


bscpak-heade r 


1-26 




Length 26 octets. 






* INACTIVE 






BSCEAK-field 


octet 


comment 


bscpak-header 


1-26 




Length 26 octets. 






* DIE 






BSCPAK-field 


octet 


comment 


bscpak-header 


1-26 




Length 26 octets. 






* LIVE 






BSCPAK-field 


octet 


comment 


bscpak -header 


1-26 




Length 25 octets. 






* VICESOSRX 






BSCPAK-field 


octet 


comment 


bscpak-header 


1-26 




Length 26 octets. 






* SOSRX 
BSCPAK-field 


octet 


comment 



bscpak-header 1-26 
Length 26 octets. 
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* GROUPLIST 










BSCPAK-field 


octet 


comment 




bscpak-header 


1 


-26 






number of MAN 


27 




1..15 




HAN 1 


29 


- 36 


only decimal 


A' " t 

lgits 


HAN 2 


37 


- 44 






HAN 3 


45 


- 52 


only decimal 


digits 


HAN 4 


53 


- 60 


only decimal 


digits 


HAN 5 


61 


- 68 


only decimal 


digits 


HAN 6 


69 


- 76 


only decimal 


digits 


HAN 7 


77 


- 84 


only decimal 




MAN 8 


85 


- 92 


only decimal 


digits 


MAN 9 


93 


-100 


only decimal 


digits 


HAN 10 


101 


-108 


only decimal 


digits 


HAN 11 


109 


-116 


only decimal 




HAN 12 


117 


-124 


only decimal 


digits 


MAN 13 


125 


-132 


only decimal 


digits 


HAN 14 


133 


-140 


only decimal 


digits 


HAN 15 


141 


-148 


only decimal 




Length 148 octets. 










* FLEXREQ 










BSCPAK-field 


octet 


comment 




bscpak-header 


1 


-26 






Length 26 octets. 










* FLEXLIST 










BSCPAK-field 


octet 


comment 




bscpak-header 


1 


-26 






number of HAN 


27 




1..7 




HAN 1 


28-35 


only decimal 


digits 


MAN 2 


36 


-43 


only decimal 


digits 


HAN 3 


44-51 


only decimal 




HAN 4 


52 


-59 


only decimal 


digits 


MAN 5 


60 


-67 


only decimal 


digits 


HAN 6 


68 


-75 


only decimal 


digits 


HAN 7 


76-83 


only decimal 


digits • 


Length 83 octets. 










* TIME 










BSCPAK-field 


octet 


comment 




bscpak-header 


1- 


-26 






time 


27- 


-36 


decimal digits (YYMMDDHHMH) 


Length 36 octets. 











A 292 31933 
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6 TRANSLATION BETWEEN ASCII AND EDCDIC 



ASCII 


EBCDIC 


09 


05 


OA 


25 


OC 


OC 


OD 


on 


20 


40 


21 


5A 


22 


7F 


23 


7B 


24 


5B 




6C 


26 


50 


27 


70 


28 




29 


5D 


2A 


5C 


2B 


4E 


2C 


6B 


2D 


60 




4B 


2P 


61 


30 


FO 


31 


Fl 


32 


F2 


33 


F3 


34 


F4 


35 


F5 


36 


F6 


37 


F7 


38 


F8 


39 


F9 


3A 


7A 


3B 


5E 


3C 


4C 


3D 


7E 


3E 


6E 


3P 


6F 


40 


7C 


41 


CI 


42 


C2 


43 


C3 


44 


C4 


45 


C5 


46 


C6 


47 


C7 


48 


C8 


49 


C9 


4A 


Dl 


4B 


D2 


4C 


D3 


4D 


D4 


-4E 


D5 
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4P D6 

50 D7 

51 D8 

52 D9 

53 E2 

54 E3 

55 E4 

56 E5 

57 E6 

58 E7 

59 E8 
5A E9 
5B 4A 
5C E0 
5D 4P 
5E 5P 
5F 6D 

60 79 

61 81 

62 82 

63 83 

64 84 

65 85 

66 86 

67 87 

68 88 

69 89 
6A 91 
6B 92 
6C 93 
6D 94 
6E 95 
6F 96 

70 97 

71 98 

72 99 

73 A2 

74 A3 

75 A4 

76 A5 

77 A6 

78 A7 

79 A8 
7A A9 
7B CO 
7C 6A 
7D DO 
7E Al 
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7 MOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references , made to • 
other sections in the terminal specification. The list 
below shows these references , together with the page(s) 
they are made on. Please note that a section could be 
. referred to several times on the same page. 

Rl-06, 4 
Rl-09, 6, 7 



Below are the reference designations listed. 
Reference Section 



Rl-01 
Rl-02 
Rl-03 
Rl-04 
Rl-05 
Rl-06 
Rl-08 
Rl-09 
Rl-11 
Rl-12 
Rl-16 
Rl-17 • 
Rl-18 
Rl-19 
Rl-20 



Arrangement of the documents 
MOBITEX System description 
General description of terminals 
Terminology 
References 

Network operator information 
Application layer 
Network layer 

Interface requirements, fixed terminals 
Other requirements, fixed terminals 
Link layer, mobile terminals 
Physical layer, mobile terminals 
Radio equipment, mobile terminals 
Other interfaces, mobile terminals 
Other requirements, mobile terminals 



The following references are made in this document: 

CCITT recommendations series V, 1984 Edition(Red 
books )X. 21 bis. 

IBM General Information - Binary Synchronous 
Communications, GA27-3004. 
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ABSTRACT 



This document is a specification of the interface for a 
fixed terminal with MOBITEX Asynchronus Communication 
(MASC) interface, connected to the MOBITEX network. 
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1 INTRODUCTION 



1.1 GENERAL 

The designation "terminal" for a fixed terminal in the 
MOBITEX network correspond to DTE in CCITT recommenda- 
tions . 

CCITT recommendation V.24 is used at the physical layer 
and MASC interface is used at. the link layer (reference 
Rl-19 is used for link layer MASC). The network layer 
consists of MPAK's according to reference Rl-09.. 
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2 PHYSICAL LAYER 



Connection is in accordance with CCITT recommendation 
V.24/V.28. 

Hote: The physical layer of MASC is not directly 

compatible with the physical layer in the raasc 
interface of a mobile terminal. 

However this can ba done by connecting the Eollowing 
signals in the mobile unit. 

105 1 

106 1 

107 1 

108/2 

109 1 



For information about permitted bitrate transmission 
rates, please see reference Rl-06. 
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3 LINK LAYER 






3 . 1 GENERAL 






The link layer sends, controls and acknowledge information 
between .network and terminal. When faults are detected, 
the link layer handles retransmission. 




The design of the link layer follows PROTOCOL FOR MASC 
TYPE TERMINALS, which is described in 'reference Rl-19. 




The data in information frame is HOB I TEX packets (MPAK) 
which are described in reference Rl-09. 




3.2 FRAMES USED IN MASC 




- 


There are two different types of frames, control frames 
and information frames {see reference Rl-19). 




The following control frames are used: 




- ACK Acknowledgement 

- NACK Negative acknowledgement 

- RACK Request for repetition of the latest sent 

ACK 

- SENS Communication link control 

- SACK Acknowledgement of a received SENS 




Note: The network' will not send the frame SENS by 
default. 




Information frames. are used with the following commands: 




- B parameters in machine interface 

- M send/receive MPAK 

- E answer to an invalid command 

- F P terminal MAN request and answer 

- F Q masc device identity 















Exhibit 2, p. 



Cantel Mohitex~ 



■ A 296 5516 Ue 



1990-02-26 



MTS11HASC.1 



3 . 3 TIMEOUT 



The masc interface uses two timers, which are described in 
reference Rl-19. 

Note: The network will handle the "30 seconds timeout" as 
follows: 

If no answer is received within 30 seconds, the 
network will return the frame to the sender. The 
network will then try to start up the line with a B- 
command . 



3.4 START WITH NO SUBSCRIPTION NUMBER 

The terminal has the possibility to ask the network about 
the valid subscription number. When the line is in the 
connected mode, the terminal can ask the network about 
MOBITEX subscription number. 

The terminal sends the P P command and receives the answer 
F PMAN from the network. The terminal will also receive an 
identification of the network in the F Q command. 

The commands F P and F Q are described in reference Rl-19. 
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4 MOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 

Rl-06, 4 
Rl-09, 3, 5 
Rl-19, 3, 5, 6 



Below are the reference designations listed. 

Reference Section 

Rl-01 Arrangement of the documents 

Rl-02 MOBITEX System description 

-R1-G3 General description of terminals 

Rl-04 Terminology 

Rl-05 . References 

Rl-06 Network operator information 

Rl-08 Application layer 

Rl-09 Network layer 

Rl-11 Interface requirements, fixed terminals 

Rl-12 Other requirements, fixed terminals 

Rl-16 Link layer, mobile terminals 

Rl-17 Physical layer, mobile terminals 

Rl-18 Radio equipment, mobile terminals 

Rl-19 Other interfaces, mobile terminals 

Rl-20 Other requirements, mobile terminals 



The following external references are made in this 
document : 

CCITT recommendations series V, 1984 Edition (Red 
books) V.24 and V.28 
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ABSTRACT 

This document describes the connection of an asynchronous 
terminal to the MP AD service in the MOB I TEX network. 
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1 INTRODDCTION 



1.1 GENERAL 

The MP AD communicates with the terminal one character at a 
time with a start-stop protocol. The purpose with the MP AD 
service is to let customers use a standard terminal for 
communication with the MOBITEX network. 

The designation "terminal" for a fixed termial in the 
MOBITEX network corresponds to DTE in CCITT recommenda- 
tions . 
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2 PHYSICAL LAYER 






2 . 1 GENERAL 






Connection is in accordance with CCITT recommendations 
V.24/V.28. 




2.2 TERMINAL EQUIPMENT 






An asynchronous terminal of start-stop type for serial 
data transmission is used. The communication uses 1 start 
bit, 8 data bits, 1 stop bit and no parity. The screen 
should be 24 lines x 80 columns. The terminal should have 
an advanced video option installed to use the reversed 
video facility. 




If the MPAD-connected terminal has a printer port or 
auxiliary -port, a printer can be connected to this port. 
Messages to/from the terminal can be directed to this 
printer if the terminal can interpret the printer-port 
setting commands described in chapter 3. 




2.3 PRINTER EQUIPMENT (optional) 




The printer should have at least 24 columns, preferably 80 
columns width. The transmission rate and communication 
type depends on the available printer-port on the 
terminal. The printer should be able to use the same 
character-set as the terminal, see chapter 3. 




2.4 BITRATE 






For information about permitted transmission rates, please 
refer to. reference Rl-06. 
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3 PROTOCOL FOR TERMINAL 

The terminal should comply with ANSI/VT100 according to 
the following specifications that is a subset of ANSI 
X3.41 1974 and ANSI X3.64 1979. 

The terminal should be able to : 

* transmit and receive all characters described in 
MOBITEX text code (please refer to reference Rl-06). 

* transmit ASCII-character 127 (DEL). 

* receive ASCII-character 7 (bell) and then give an 
audible signal. 

* receive ASCII-character 10 (LF) and then do a line- 
feed. 

* receive ASCII-character 13 (CR) and then do a 
carriage return. 



interpret the control sequences described in chapter 
3.2 
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3.1 CONTROL SEQUENCES FROM TERMINAL TO MPAB 

The following control sequences should preferably be 
generated by arrow-marked keys. 

ESC O A (arrow up) 

ESC 0 B (arrow down) 

ESC O C (arrow right) 

ESC O D (arrow left) 

The following control sequences should preferably be 
generated by the keys on an auxiliary "keypad. 



ESC 


0 


p 


(0) 


ESC 


0 


q 


(1) 


ESC 


0 


r 


(2) 


ESC 


0 


s 


. (3) 


ESC 


0 


t 


(4) 


ESC 


0 


u 


(5) 


ESC 


0 


V 


(6) 


ESC 


0 


w 


(7) 


ESC 


0 


X 


(8) 


ESC 


0 


y 


(9) 


ESC 


0 


m 


(dash) 


ESC 


0 


1 


(=lowercase D) (c 


ESC 


0 


n 


(period) 


ESC 


0 


M 


(ENTER) 


ESC 


0 


P 


(PF1) 


ESC 


0 


Q 


(PF2), 


ESC 


0 


R 


(PF3) 


ESC 


0 


S 


(PF4) 



3.2 CONTROL SEQUENCES FROM MPAD TO TERMINAL 

ESC = Set terminal in keypad application mode 

ESC 7 Save cursor 

ESC 8 Restore cursor • 

ESC [ 7 m Set reverse video 

ESC [ 0 ra All video attributes off 

ESC [ 5 i Enter printer controller mode 

ESC [ 4 i Exit printer controller mode 

ESC [ 0 k Erase line after cursor 

ESC E Next line 

ESC [ 20 h Set new line mode 

ESC [ x;y H Move cursor to line x and column y 

ESC [ ? 1 (=one) h Set cursor key mode 

ESC [ 2 J Erase all of the display 
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4 MOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to- 
other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 

Rl-06, 4, 5 



Below are the reference designations listed. 



Reference Section 

Rl-01 Arrangement of the documents 

Rl-02 MOBITEX System description 
Rl-03 ' General description of terminals 

Rl-04 Terminology 

Rl-05 References 

Rl-06 Network operator information 

Rl-08 Application layer 

Rl-09 Network layer 

Rl-11 Interface requirements, fixed terminals 

Rl-12 Other requirements, fixed terminals 

Rl-16 Link layer, mobile terminals 

Rl-17 Physical layer, mobile terminals 

Rl-18 Radio equipment, mobile terminals 

Rl-19 Other interfaces, mobile terminals 

Rl-20 Other requirements, mobile terminals 



The following external references are made in this 
document : 

CCITT recommendations series V, 1984 Edition {Red 
books) V.24 and V.28 

ANSI X3.41 1974 
ANSI X3.64 1979 
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ABSTRACT 

This document specifies general requirements for fixed 
terminals, connected to the MOBITEX network. 
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1 GENERAL 

A fixed terminal is connected with a line interface for 
packet switching and line connection for line connection 
traffic (priraar ily' speech ) . If the fixed terminal is 
connected to the mains, there are certain requirements for 
electrical safety. 




2 ELECTRICAL SAFETY 






For information about electrical safety requirements, 
please refer to Rl-06. 




3 SPECIFICATION OF LINE 


CONNECTION 




A fixed terminal should permit line connection traffic as 
a comolement to message traffic. For this to be possible, 
it is" necessary to have a real time connection between 
terminal and network in addition to the message traffic 
interface. A connection of this type can be used for 
transmitting speech for example. 




For information about line connection requiremements, 
please refer to Rl-06. 




TYPE OF CONNECTION: 
CONNECTION: 


4 wire speech connection with 
one speech direction per line 
pair. 

ISO DIS 8877 plug of European or 
D.S. type. 




FREQUENCY RANGE: 


300 - 3400 Hz 




RECEIVER LEVEL DIRECTION 


-15 30 dBm 




SENDER LEVEL DIRECTION 


-10 — -23 dBm 




SIGNAL/NOISE RATION REC./SEND. : Greater than 40 dB 









A.232SISM 
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4 MOB I TEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with- the page(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 

Rl-06, 3 



Below are the reference designations listed. 

Reference Section 

Rl-01 Arrangement of the documents 

Rl-02 . MOBITEX System description 

Rl-03 . General description of terminals 

Rl-04 Terminology 

Rl-05 References 

Rl-06 Network operator information 

Rl-08 Application layer 

Rl-09 Network layer 

Rl-11 Interface requirements, fixed terminals 

Rl-12 Other requirements, fixed terminals 

Rl-16 Link layer, mobile terminals 

Rl-17 Physical layer, mobile terminals 

Rl-18 Radio equipment, mobile terminals 

Rl-19 Other interfaces, mobile terminals 

Rl-20 Other requirements, mobile terminals 
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EXPLANATION AND MODIFICATIONS 

This chapter has been newly added. It is an addendum providing a preliminary 
specification of additional requirements for portable terminals designed for 
operation on the Mobitex network. The primary motivation for this addendum is 
the need to provide a low power operating mode for portable units, to extend 
the operating time of their self-contained batteries. Because enhancements have 
been made to network signalling protocols over the air interface, these 
additional requirements will have some effect on the operation of mobile units 
as well. A careful review of this chapter is therefore required of all terminal 
designers and manufacturers. 

Since the addendum document was printed, several changes have been made 
to the protocol. They will be included in a future revision of the ERfTEL - 
provided specification. These changes, which should be . applied to the MTS 
15.1 document immediately following, are detailed below so that this very 
important new information can be brought to the attention of interested parties 
in a timely manner. 

1. Section 3.5, page 8: the first paragraph should be changed to read: 

If the terminal has lost consecutive <SVP6> signals over a period 
less than 60 seconds, it should remain in the operating state to 
synchronize again. If the terminal has not succeeded in synchronizing 
within 60 seconds, it should initiate the roaming procedure. 

2. Section 3.6, page 12; the two paragraphs under the heading 'Evaluation of 
other base stations" should be changed to read: 

The evaluation of base stations on the CURRENT-SYSTEM-CHANNEL 
should be based on the average received signal strength over a time 
period indicated in <SVP6> (default value, 60 seconds). 

The integration time for evaluating base stations on other channels is 
indicated in <SVP6> (default value, 3 RSSI-PERIODS). . 

3. Section 3.8.1, page 13: the second paragraph under the heading "UP LINK 
TRAFFIC" should be changed to read: 

For uplink traffic the terminal should enter the OPERATING state and 
then follow the norma! access rules, Le., wait for a <FRI> signal and 
then choose a random slot in which to transmit 



4. Section 3.10, page 17: This section deals with voice operation and may be 
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5. Section 4, pages 25 and 28: Note that the <SVP5> and <SVP6> may 
contain up to 186 MANs each. A parameter will be added in the currently 
unused portion of the primary block of <SVPS> and <SVP6> to indicate 
the number of MANs in the man list or traffic list, respectively. 

6. Section 4, pages 28 and 29: parameters will be added in the currently 
unused portion of the primary block of <SVP6> to indicate signal strength 
evaluation times for the CURRENT-SYSTEM-CHANNEL (default 60 seconds) 
and other channels (default 3 RSSI-PERIODS). (See item 2. above). 

7. Section 4, page 29: the entry for TRANSACTION-TIME" should be changes 
to read: 

States the time the terminal should stay in OPERATING state after (1) 
reception of a message from the network, and (2) transmission of a 
message to the network. (0-255) X 250 ms. Default value: 40 (10 
seconds). TRANSACTION-TIME starts after transmitting or recieving an 
<ACK>, respectively. 

8. Section 6, pages 35 and 36: the following three items listed as design 
recommendations have been changed to design requirements, and their 
functionality must be included in portable units: 

Automatic change to mobile terminal operation (page 35) 

User notification of 'lost contact* (page 36) 

Display RSSI to user before transmitting (page 36) 

The remaining three items - manual selection of operating mode, prevention 
from automatic quick channel monitoring, and manual initiation of channel 
monitoring - continue to be design recommendations. 



ADDITIONAL INFORMATION 

In the "INFO" MPAK (See MTS 09A.2, pages 107 and 108), portable terminals 
will be defined as terminal type number 4.The INFO MPAK will also now include 
a parameter indicating the operating mode of the portable unit (mode = mobile 
terminal mode; mode 1 = battery saving mode). 

In the MASC interface (see MTS 19A.2), new commands will be added to 
accommodate portable terminals. Deta'ls will be provided later. 
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ABSTRACT 



This document specifies additional requirements for hand- 
held portable terminals to be connected to the MOBITEX 
system. 

An interface for hand-held portable terminals, where power 
conservation is one prime objective, is defined. 

This document should be considered as an ADDENDUM to the 
MOBITEX Terminal Specification (MTS ) for 8 kbps mobile 
terminals, LZBA 703 1001, R1A. 
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1 INTRODUCTION 

This document specifies additional requirements for hand- 
held portable terminals to be connected to the MOB I TEX 
system. 

It should be considered as an ADDENDUM to the complete 
MOBITEX Terminal Specification for 8 kbps mobile 
terminals, LZBA 703 1001, R1A. 

If certain requirements are made for hand-held portables 
these are made in this document. It could either be new 
additional requirements or new requirements that replaces 
ones that are made in the specification for ordinary 
mobile terminals. 



2 GENERAL DESCRIPTION 

A hand-held_por table terminal is basically a mobile 
terminal and should therefore conform to the requirements 
for mobile terminals, but with the additional ability to 
go into low power drain operating mode and wakeup when 
required to receive messages from the network. 

When the hand-held has received its messages it goes 
asleep again. 

One limitation for portables in this mode is that messages 
to these terminals may be delayed during the time when the 
portable is asleep. 

Whenever a hand-held wants to send a message it 
immediately wakes up, waits for a free-signal and sends 
the message. The terminal then stays awake for a period of 
time in order to be be able to receive a quick message 
response. 

The roaming procedure is essentially the same as for 
ordinary mobiles, but is controlled from separate sweep- 
parameters for hand-held terminals. The hand-held 
terminals performs the base evaluation during its awake 
time . 
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This protocol for hand-held terminals defines four new 
subtypes of the sweep-signal, <SVP>. These subtypes are 
numbered from 3 to 6.. 



<SVP3> - Sweep frame of subtype 3 

Includes roaming parameters and channel list used by 
hand-held terminals. <SVP3> corresponds to <SVP1> 
used by mobile terminals. 



<SVP4> - Sweep frame of subtype 4 

Contains channel numbers and channel types used in 
fleet division procedure. <SVP4> corresponds to 
<SVP2> used by mobile terminals. 



<SVP5> - Svzeep frame of subtype 5 

Contains a list of— terminal MAN that has messages 
stored in the network mailbox. 



<SVP6> - Sweep frame of subtype 6 

Contains a list of terminal MAN or Group MAN that 
will have traffic from the network during this sweep 
cycle. 

This sweep frame also contains timing parameters for 
synchronization and message transfer. 
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3 OPERATING PRINCIPLES 



3.1 START OP PROCEDURE 

When the portable is powered up for the first time and/or 
when it has lost synchronization with the network or lost 
important information/parameters, it should consider 
itself to be in normal mobile terminal mode and act 
according to that. 

When the hand-held has found a system channel on a base 
station to use, received the relevant parameters from the 
base and synchronized to it, the terminal should send MPAK 
ROAM or ACTIVE according to the roaming procedure. 

The hand-held always has the possibility to go to normal 
mobile terminal mode , e.g. when the terminal is put in a 
power charger or for a major data transaction session when 
you want to be active all the time. In order to inform the 
network of this change of mode, the hand-held sends a new 
MPAK called MODE. 



3.2 STATES 

There are two different states that a hand-held terminal 
could enter when it is in the low power drain mode; 
STANDBY state or OPERATING state. 

The STANDBY state should be considered as a 'sleeping' 
mode where only time keeping functions for synchronizing 
the terminal to the base station are in operation. 

In the OPERATING state the terminal should be considered 
as fully operational. 
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3.3 TRAFFIC LIST 

The hand-held terminal is notified in a TRAFFIC LIST that 
traffic will sent to the terminal. 

The TRAFFIC LIST contains the TERMINAL-MAN or the GROUP- 
MAN of those terminals that should remain in the OPERATING 
state in order to be available for the down-link traffic 
from network. 

The TRAFFIC LIST is part of a new <SVP>-frame of SUBTYPE 
6, denoted <SVP6>-f rame. 

Terminals not included in the TRAFFIC LIST may directly go 
back to STANDB5J state in order to save battery. 



3.4 MAIL LIST 

Messages not acknowledged by the terminal may be stored in 
the' network mailbox according to. the conditions describes 
•in Rl-09, 8kbps MTS. 

In order to inform terminals that have messages in the 
network mailbox, the MAIL LIST is introduced. 

The MAIL LIST contains a list of. those terminal MAN having 
messages in the mailbox. The MAIL LIST is within the 
<SVP>-frame of subtype 5, denoted <SVP5>. 
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3.5 SYNCHRONIZATION TO THE NETWORK 

Hand-held terminals using the this battery saving protocol 
cyclically goes from the STANDBY state to the OPERATING 
state. 

The terminal must be synchronized to the <SVP6> (TRAFFIC 
LIST) sent from the network. The <SVP6> frame is sent 
periodically from the network on the system channels where 
hand-held terminals can operate and use the battery saving 
protocol. 

The <SVP6> also contains the parameter TIME-TO-NEXT 
indicating the remaining period of time from this <SVP6> 
to the next time the terminal should enter the OPERATING 
state. 

TIME-TO-NEXT = time from first bit (bit 1) in the 

framehead of the received <SVP6> to the 
next time the terminal should enter the . 
OPERATING state. 

The <SVP6> also contains the parameter CYCLE-TIME which is 
the nominal cycle time between the start of two operating . 
states. 

The length of the CYCLE-TIME parameter is a compromise 
between response-time requirements and power consumption 
requirements of the terminal. 

Normally the terminal uses the TIME-TO-NEXT parameter in 
the <SVP6> to synchronize to the next time to enter the 
OPERATING state. If one or more of the <SVP6> frames are 
lost, the terminal should use the CYCLE-TIME parameter in 
order not to lose synchronization. 

Once the terminal has entered the OPERATING state it 
remains in this state until it receives an <SVP6> frame 
with a TRAFFIC LIST where the terminal is not included. 
The <SVP6> is terminating the transmission of the sweep 
frames . 

If the network is going to send other sweep frames when 
the terminals are In the OPERATING state, they will be 
sent prior the <SV?6> frame. 

If none of the <SV"P3> to <SVP6> has been received within 2 
seconds from the transition to the OPERATING state, the 
terminal could return to STANDBY. 

After the reception of every <SVP3> to <SVP5> the terminal 
stays in OPERATING state for another 2 seconds or till it 
receives an <SV?6>. 
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If the hand-held consider itself as having lost 
synchronization to che network, e.g. lost of a number o? 
consecutive <SVP6>, it should stay in OPERATING sfcat* to 
synchronize again. 

Example 1 : 



Terminal uses TIME-TO-NEXT for synchronizing. 




Terminal — 'OPR 



OPR = terminal in OPERATING state 
— S_TJB._= terminal in STANDBY state 



Example 2 : 

Terminal is using the CYCLE-TIME when <SVP6> is lost to 
keep synchronization. 

Base <SVP6> <XXX> <SVP6> 

I I 

I blME-TO-NEXTj FtIME-TO-NEXT 

" CYCLE-TIME 1 CYC LE-TIME i CYCLE-TIME - 

Term— OPR ' STB J 0Pr' STB 'opr' STB" 

OPR = terminal in OPERATING state 
STB = terminal in STANDBY state 



Multiple sweep frame could be sent during the OP ERAtt in- 
state. 

Base <SVP3> , <SVP4> , <SVP5> , <SVPS> 

I I i I 

I < TIME-TO— NEXT 

I ' C YCLE-T I ME " ; 
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Example 4 : 



Terminal does not receive any sweep frame within 2 seconds 
from the start of the OPERATING state and returns to 
STANDBY. 



Base 



—CYCLE-TIME - 



Example 5: 

The terminal receives a <SV?3> but the <SVP6> is not 
received so the OPERATING state is terminated by the 2 
second timeout. 

The timeout-is counted from the reception of the <SVP3> 
frame. 



<SVP3> 
I 



—CYCLE-TIME 
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3 . 6 ROAMING 






The roaming procedure for hand-held terminals follows 
basically the roaming procedure for mobile terminals 
described in Rl-16. 




Since a hand-held terminal is most of the time in the 
STANDBY state, the normal monitoring of the roaming 
procedure must be carried out during the time when the 
terminal is in the OPERATING state. During the OPERATING 
state the terminal measures the averaged received signal 
strength and calculates a roaming value. 




The system parameters controlling the roaming procedure 
for hand-held portables are defined in the <SVP3>-f rame. 
This gives the possibility to have different parameters 
for mobile terminals, (defined in the <SVP1> frame ) and 
for hand-held portables. 




In order to control the performance of the terminals 
roaming procedure, different roaming parameters can be set 
in the <SVP3>-frame from the network. Here aresome 
examples described and the impacts on the terminals 
performance. 




Example 1: 






If SCAN TIME = 0 the terminal only monitors the 
CORRENT_SYSTEM_CHANNEL during the OPERATING state. 




Ac evaluation, if the roaming value < BAD_BASE the 
terminal goes to the 'quick channel monitoring' procedure 
since no other channels has been detected. 




Base : <SVP6> 


<SVP6> 




Immml 


Immml 




Term : -'OPR 1 STB 'oPR 1 STB 




m = monitor CURRENT SYSTEM CHANNEL 
OPR = terminal in OPERATING state 
STB = terminal in STANDBY state 




The other sweep frames are not shown in this figure but 
are coming before the <SVP6> frame if they are sent out. 
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If SCANJTIME = 1 ... 255, the terminal monitors other 
channels according to the channel list information the 
mobile has derived in the <SVP3> or from the default list. 

The start of the scan period is only critical in that 
sense that the terminal must not leave the svstera channel 
and monitor another channel when it should be in OPERATING 
state. 

The terminal should not leave CURRENT_SYSTEM_CHANNEL and 
monitor other channels during the sweer> cycle if it is 
addressed in the TRAFFIC LIST. 




m = monitor CURRENT_S Y S TEM_CHANNEL 
s = scan other system channels 
r = RSSI_PERIOD 
OPR = terminal in OPERATING state 
STB = terminal in STANDBY state 

Please see the chapter ROAMING in Rl-16 for further 
information. 
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Criteria for leaving base : 

The same criteria for leaving the CURRENT_BASE applies for 
a hand-held terminal as the mobile terminal but with the 
parameters in the <SVP3> frame. The fifth criteria (item 
-5-) is not valid for hand-held terminals. 

Please see the chapter ROAMING in Rl-16 for further 
information. 



Evaluation of other base stations : 

The evaluation of base stations on the CURRENT_SV STEM- 
CHANNEL, should be based on the averaged received sianal 
strength from at least 60 seconds or some other suitable 
integration time. 



When evaluating other channels than the 
- CORRENT_SZSTEM_CHANNEL Y -r-oaming- values from at least three • 
(3) RSSI_PERIODS should be averaged. 



Quick channel monitoring : 

In quick channel monitoring when the SCAN_TIME = 0 and 
when the terminal has found a channel with a 
roaming value > GOOD_BASE, the terminal should remain on 
the channel for at least 5 seconds during the measuring of 
received signal strength. Please refer to 'quick channel 
monitoring' part (item -4-). of the ROAMING chapter in 



At Power On 



When the hand-held terminal is switched on it should use 
the stored CURRENT_SYSTEM_CHANNEL and the CORRENT_BASE . 

If there is no CURRENT_B AS E stored the terminal directly 
starts the quick channel monitoring procedure using the" 
default list of system channels. When a CURRENT SYSTEM- 
CHANNEL and a CURRENT_B-A.SE has been found and the MPAK 
ROAM has been sent to the network, the terminal 
synchronizes to the <SVP6>-f rames . 
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3.7 FLEET DIVISION OF HAND-HELD PORTABLES 

In order to assign a certain system channel (and/or access 
channel) to hand-held terminals or parts of the fleet of 
the hand-held terminals a <SVP>-f rame of SUBTYPE 4 is 
introduced, denoted <SVP4>-f rame. The <SVP4>-f rame should 
be interpreted in same way as the <SVP2>-f rame for mobile 
terminals, described in 8kbps MTS section Rl-16. 



3.8 MESSAGE TRANSACTIONS 
3.8.1 OP LINK TRAFFIC 



The access requirements for up-link traffic from a hand- 
held terminal are basically the same as for a mobile 
terminal. 

A hand-held terminal that is going to transmit a message"".' 
to the network enters the OPERATING state directly and 
waits, for a valid <FRI>-frame from the network according 
to the 8kbps MTS. 

When the terminal makes an access request for data using 
the <ABD>-frame , the terminal should follow the 8kbos MTS 
dialogues and remain in OPERATING state till the <MRM>- 
frame is transferred successfully or when the dialogue 
terminates for any reason. 



After the message is successfully transferred to the 
network the hand-held terminal remains in OPERATING state 
for TRANSACTION-TIME, defined in <SVP6>, before it goes 
back to STANDBY state. This gives a possibility for 
transferring an answer back to the hand-held without any 
delays caused by the waiting time to the next TRAFFIC LIST 
transmission. This function could be considered as if a 
'logical down-link channel' has been opened to the 
terminal for TRANSACTION-TIME. 
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3.8.2 DOWN LINK TRAFFIC 




Hand-held terminals having down-link traffic is addressed 
in the TRAFFIC CIST. 




When the hand-held terminal receives a TRAFFIC LIST that 
contains one of its terminal addresses (TERMINAL MAN or 
GROUP MAN) it stays in OPERATING state and awaits one 
message. 




When the message is successfully received the terminal 
stays in OPERATING state for TRANSACTION-TIME in order to 
be able to receive more down-link messages cominq from the 
network. The parameter TRANSACTION-TIME is included in the 
<SVP6>-frame, and is the same as for up-link traffic. 




If no message has been received within the TRANSACTION- 
TIME elapsed from the reception of the last message, the 
terminal can leave OPERATING state. 




.. The terminal can also leave OPERATING state when it 

receives a TRAFFIC LIST without any of the terminal 
addressees. 




When a hand-held terminal is ordered to another channel 
for down-link data transmission, <BKD> frame from network, 
the hand-held terminal should remain in the OPERATING 
state until the data transmission dialogue is completed 
according to the 8kbps MTS. 




Terminals not included in 
to STANDBY state in order 


the TRAFFIC LIST may directly go 
to save battery. 




Example 1: 






Terminal is not in traffic list 




Base : <SVP6> 

1 


<SVP6> 
1 




Term :^OPr' ' " STB 


— " ' OPR ^ STB 




OPR = terminal in OPERATING state 
STB = terminal in STANDBY state 
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Example 2: 



Terminal is in traffic list of <SVP6> and the 
network has one <MRM> to transmit. 



<SVP6> <MRM> 



<SVP6> 
I 



TT = TRANSACTION— TIME 

OPR = terminal in OPERATING state 

STB = terminal in STANDBY state 



Example 3: 



Terminal is in traffic list of <SVP6> and the 
network transmits multiple <MRM> within the sweeD 
cycle. - r • 



<SVP6> <MRM> <MRM> 



j_ TT _J_ , 



TT = TRANSACTION-TIME 

OPR = terminal in OPERATING state 

STB = terminal in STANDBY state 
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3 . 9 ACTIVATION/INACTIVATION 

The hand-held terminal use of the ACTIVE/INACTIVE packet 
has been modified to better suit their environment and 
application. 

Hand-held portables used in-doors will lose contact with 
the network. much more frequently then mobile terminals. 
Hand-held terminals should therefore not send ACTIVE due 
to "lost contact' according to the roaming procedure since 
this will cause considerable system signalling overhead. 

Hand-held terminals should send INACTIVE / ACTIVE when 
switched-of f and switched-on respectively. 

When a hand-held terminal is addressed in the MAIL LIST it 
has the possibility to empty the mailbox by sending an 
ACTIVE packet. 



Terminal is in mail list of <SVP5> and the network 
has one or more <MRM> placed in mailbox. 



Base : <SVP5> <ACK> <MRM2> <SVP6> 
III I 



TT = TRANSACTION-TIME 

OPR = terminal in OPERATING state 

STB = terminal in STANDBY state 

MRM1 = MPAK ACTIVE 

MRM2 = any MPAK from mailbox 
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3.10 LINE CONNECTION 

Call set-up and disconnection procedures for line 
connection to a hand-held terminal follows the 
requirements in the 8kbps MTS. 

When a hand-held terminal is called from the network for a 
line connection, the terminal is addressed in the TRAFFIC 
LIST with the TERMINAL MAN or one of the GROUP MAN. The 
terminal remains in the OPERATING state and follows the 
normal procedure for call set-up described in the 8kbps 
MTS. The terminal can leave the OPERATING state when the 
call is disconnected, according to the dialogues in the 
8kbps MTS. 



When a hand-held terminal initiates a call set-up for a 
line connection, the terminal enters OPERATING state 
before sending the line connection request, and stays in 
this state until the call is disconnected, according to 
the 8kbps MTS. _ 
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4 ADDITIONAL FRAMES - DATA LINK LAYER 


FRAME TYPE <SVP>, Sweep signal 


APPLICATION The sweep signal is a periodically 

recurring signal from BASE. An <SVP> is 
transmitted by. BASS for two reasons: 


1) 


<SVP> marks the start of a sweep 
cycle. 


2) 


<SVP> contains system 
parameters . 


<SVP> has 
terminals 
portable 


2 different subtypes for mobile 
and 4 subtypes for hand-held 
terminals : 


SUBTYPE 1 


states the values of system 
parameters for mobile terminals 


2 


states the frequency of 
different channel types for 
mobile terminals 


3 


subtype only for hand-held 
terminals using the battery 
saving protocol described in 
this document. This subtype 
contains the system parameters 
for the hand-held terminals. 


4 


states the frequency of 
different channel types for 
hand-held terminals. 


5 


includes the MAIL LIST nor 
terminals (may be used both by 
mobile terminals and hand-held 
terminals) 


6 


includes the TRAFFIC LIST and 
the timing parameters for hand- 
held terminals 


Note 1: <SVP> of subtype 
Addendum. Please 


1 and 2 are not described in this 
refer to 8kbps MTS Rl-16. 


Note 2: For <SVP5> and <SV?6>, the hand-held should use 
correctly received zollowing blocks, even chougn 
the whole frame may not be correct. 
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<SVP>, 


SUBTYPE 3 


- states the values of system 
parameters for hand-held 
terminals. 


PRIMARY BLOCK 












01 02 03 


22 


23 24 


25 26 27 


28 29 30 31 32 






MOB 


0 0 0 


0 1111 






33 34 35 


36 37 38 


39 40 


41 42 43 


44 45 46 47 48 






PRIO 


MASK 


BLOCK 






49 50 .51 


52 53 54 
i i i 


55 56 


57 58 59 


60 61 62 63 64 






SVPTYP 




TXPOW 






65 66 67 


68 69 70 
i i i 


71 72 


73 74 75 


76 77 78 79 80 
i i i i 






RSSI_PROC 


RSSI_PERIOD 






81 82 83 
r i 


84 85 86 
i i i 


87 88 


89 90 91 


92 93 94 95 96 






0 0 0 


0 0 0 


0 0 


MAX_REP 






97 




104 


105 


112 






BASEST 


SCAN_TIME 






113 


i i i 


120 


121 
i i 


128 






BAD_BASE 


GOOD_BASE 






129 




136 


137 


144 






BETTER_BASE ' 


0 0 0 


0 0 0 0 0 






145 
I i 


1 ! ! 






160 










PAR 
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SVPTYP 


States the <SVP> subtype / value 
00000011 in this case"." 


TXPOW 


States the decrease in output 
power {0-255 dB below nominal, 
level) to be used by the hand- 
held terminal. The default value 
of 0 is used until this signal 
is received. 


RSSI PROC 


States the method of the signal 
strength measurement: 

0 = FRAME 

1 = CONTINUOUS 

The default value is FRAME. 


RSSI_PERIOD 


Time used by the roaming 
algorithm (0-255 *20 ms) . 
Default value: 148 (2 960 ms ) . 


MAX_REP 


States the value of the .variable 


BASEST 


States status of base station. 


SCAN_TIME 


States the length of a period 
(0-255 *100 ms) when the hand- 
held terminal scans other system 
channels . 

Default value: 30 (3 seconds). 


BAD_BASE 


Used by the roaming algorithm. 
0-255 dBuV. Default value: 15. 


GOOD_BASE 


Used by the roaming algorithm. 
0-255 dBuV. Default value: 15. 


BETTER_BASE 


Used- by the roaming algorithm. 
0-255 dB. Default value: 10. 
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If any, they contain a list of 
system channels to be used in 
base station monitoring. A frame 
with a list containing new 
system channels completely 
overrides the previous frame. 
The channel list has the 
following format (as described 
in the MAIN DOCUMENT) : 



01 02 03 04 05 06 07 08 


09 10 11 12 13 14 15 16 

! ! 1 1 1 l ' 


number of channels 


0 0 0 00.0 0 0 


17 32 


33 48 


channel #1 - UPFREQ 


j '■ 1 1 ' 

channel #1- - DOFREQ 


49 " 64 
ii ii 


65 80 


channel #2 - UPFREQ 


channel $2 - DOFREQ 


81 96 

1 1 1 . I I 


97 112 
! 1 1 1 


channel #3 - UPFREQ 


channel #3 - DOFREQ 


113 128 


129 144 


channel #4 - UPFREQ 


channel #4 - DOFREQ 


145 160 
" 1 1 1 1 i 1 1 I I i i i i i | 



PARITY 



The number of following blocks depends on the size of the 
list. The maximum number of channels in the list is stated 
in reference Rl-06. 

Continues with following block #2 on the nex: page. 



FOLLOWING BLOCKS 



FOLLOWING BLOCK #1 
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FOLLOWING BLOCK #2 



channel #5 - UPFREQ 



channel #5 - DOFREQ 



channel #6 - UPFREQ channel #6 - DOFREQ 



channel #9 - UPFREQ 



144 145 ( 160 
PARITY 



FOLLOWING BLOCK #3 



channel #9 - DOFREQ 



channel #10 - UPFREQ 



channel #10 - DOFREQ 



channel #11 - UPFREQ 
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<SVP>, SUBTYPE < 



- states the frequency of 
different channel types for 
hand-held terminals." 



PRIMARY BLOCK 

01 02 03 j 22 23 24 25 26 27 28 29 30 31 32 

MOB 



0 0 0 



0 1 1 11 



33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 ■ 



PRIO 


MASK 


i i i i t i i 
BLOCK 


49 


50 51 
i 


52 53 


54 55 56 
i i 


57 


58 59 60 61 


62 


63 64 


SVPTYP 


CHATYP 


65 


66 67 


68 69 


70 71 72 
i i 


73 


7.4 75 76 77 
i i t 


73. 


7-9-80 


UPFREQ 


81 


82 83 
i 


84 85 
i 


86 87 88 


89 


90 91 92 93 


94 


95 96 


DOFREQ 


97 


98 99 


100 
i 










144 


0 


0 0 


0 0 


0 




0 0 0 


0 


o oj 



Exhibit 2, p. 



■ A 296 5084 Oe 



States the <SVP> subtype, value 00000100 
in this case. 



1 Local system channel opened 

2 Not used (ignore that order) 

3 Local system channel closed 
(return to previous system 
channel) 

4 Access channel opened 

5 Access channel closed 

UPFREQ Frequency number for up frequency, i.e. 
the frequency on which the terminal 
transmits. 

DOFREQ Frequency number for down frequency, i.e. 

the frequency on which BASE transmits. 



FOLLOWING BLOCK - No following blocks in this type 

• of frame. 
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<SVP> , 


SUBTYPE 


5 


- contains a list of terminal 
MAN chat has messages stored 
in the network mailbox 




PRIMARY BLOCK 














01 02 03 
i i 


22 


23 24 


25 26 27 

i i 


28 29 30 31 32 








MOB 


0 0 0 


0 1111 








33 34 35 


36 37 38 
i i i 


39 40 


41 42 43 


44 45 46 47 48 








PRIO 


MASK 


BLOCK 








49 50 51 

1 1 


52 53 54 55 56 


57 58 59 


60 61 62 63 64 
! 1 1 !__ 








SVPTYP 


0 0 0 


0 0 0 0 0 








6-5 66 67 


68 69 70 71 72 


73 74 75 


76 77 78 79 80 
-. . 1 ' 1 1 








0 0 0 


0 0 0 


0 0 


0 0 0 


0 0 0 0 0 








81 82 83 
L ..1 i 


84 85 86 87 88 


89 90 91 

I II 


92 93 94 95 96 
i i i i 








0 0 0 


0 0 0 


0 0 


0 0 0 


0 0 0 0 0 








97 


I I 1 


104 


105 


112 








0 0 0 


0 0 0 


0 0 


0 0 0 


0 0 0 0 0 








113 

i i i 


.1 1 1 


120 


121 


128 
i i i i 








0 0 0 


0 0 0 


0 0 


0 0 0 


0 0 0 0 0 








129 




136 


137 

. 1 1 1 


144 








0 0 0 


0 0 0 


0 0 


0 0 0 


0 0 0 0 0 








145 


1 1 1 






160 

_ ill! 








PARITY 






SVPTYP 




States the <SVP> subtype, value 
00000101 in this case. 
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FOLLOWING BLOCKS 

FOLLOWING BLOCK #1 
01 



Containing a list of terminal 
MAN that has been stored in the 
network mailbox. 



The number of following blocks depends on the size of the 
list. 

Continues with following block #2 on the next page. 
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FOLLOWING BLOCK #2 




etc. 
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<SVP>, 


SUBTYPE 




- contains the timing parameters 
used in synchronization and 
message transactions 


PRIMARY BLOCK 












01 02 03 

I 1 


22 
i i 


23 24 


25 26 27 
i i 


28 29 30 31 32 
1 i i i 






MOB 


0 0 0 


0 1111 






33 34 35 


36 37 38 
i i i 


39 40 


41 42 43 
i i 


44 45 46 47 48 
i i i i 






PRIO 


MASK 


BLOCK 






49 50 51 


52 53 54 
i i i 


55 56 


57 58 59 
i i 


60 61 62 63 64 






SVPTYP 


CYCLE-TIME 






65 66 67 


68 69 70 71 72 


73 74 75 
i i 


76 77 78 79 80 






TIME— TO— NEXT 


TRANSACTION— TIME 






81 82 83 


84 85 86 87 88 


89 90 91 


92 93 94 95 96 
[_ 1 i ' 






0 0 0 


0 0 0 


0 0 


0 0 0 


0 0 0 0 0 






97 

I I 




104 


105 


112 






0 0 0 


0 0 0 


0 0 


0 0 0 


0 0 0 0 0 






113 


I I 1 


120 
I 


121 


128 
i i i i 






0 0 0 


0 0 0 


0 0 


0 0 0 


0 0 0 0 0 






129 


I i 1 


136 


137 


144 






0 0 0 


0. 0 0 


0 0 


0 0 0 


0 0 0 0 0 






145 








160 






PARITY 
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CYCLE-TIME 



TIME-TO-NEXT 



TRANSACTION-TIME 



States the cycle time between 
two OPERATING states (0-255 x 
250 ms) . 

States the time to the next 
<SVP6> frame (0-255 x 250 ms). 

States the time the terminal 
should stay in OPERATING state 
after 1) reception of a message 
from the network and 2) 
transmission of a message to the 
network (0-255 x 250 ms). 
Default value: 80 (20 seconds. 
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FOLLOWING BLOCKS 



FOLLOWING BLOCK #1 



?A3 MTS15.1 



Containing a lisb of terminal 
MAN or group MAN that are going 
have down-link traffic during 
this sweep cycle. 



The number of followina blocks depends on the size of the 
list. 



Continues with following block #2 on the next page. 
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FOLLOWING BLOCK #2 
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5 ADDITIONAL MPAK - NETWORK LAYER 



A new MPAK is included for terminals using the battery 
saving protocol. The MPAK is used to inform, the network 
that the terminal has changed from battery saving mode to 
operate as a normal mobile terminal and vice versa. 

The new MPAK is within the packet class DTESERV (3) and 
has the packet type = 24. 



MODE (mode information) : 

Designated sender; 

The hand-held portable terminal. 



Designated addressee: 
The network. 



Raised flags: 
No raised flags. 



Criteria for generating the packet: 

When hand-held portable terminal changes from the battery 
saving protocol to operate as a mobile terminal this 
packet is used to inform the network. 

The same packet is sent to the network, but with a 
different mode identifier, when the terminal enters the 
battery saving protocol from being operating as a mobile 
terminal. 
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The network's normal action when receiving the packet: 

The network registers how the terminal operates, and 
forwards down-link traffic to the terminal in accordance 
to this. If terminal is using the battery saving protocol, 
the terminal is addressed in the TRAFFIC LIST. 

If the terminal is operating as a mobile terminal the 
network sends traffic immediately to the terminal. 



The terminal's normal action when receiving the packet: 
The terminal does not normally receives this packet. 



Length of the packet: 
9 octets. 



Exhibit 2, p. 



10S6 - A 296 6084 Ue 



90-05-11 PA3 MTS15.: 



MODE as generated by the terminal : 
MP AK— COMMON COMPONENT: 



octet 1-3: 
octet 4-6: 
octet 7: 
octet 8: 



sender: the terminal 



addressee : the Mobitex Network 



0 0 0 0 



110 0 0 



TYPE DEPENDENT COMPONENT: 



mode identifier 



mode identifier : 

0 = mobile terminal operation 

1 = battery saving protocol operation 
2-255 = reserved 
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6 DESIGN RECOMMENDATIONS 



Manual selection o£ Battery saving operating mode - Mobile 
terminal operating mode 



When the hand-held terminal is mounted into a battery 
charger in a car for example, it is recommended that 
terminal leaves the battery saving protocol operation and 
operates as mobile terminal. In chat case the user or the 
terminal itself initiates the transmission of the MPAK 
MODE to the network. The MPAK MODE will then identify the 
operating mode the terminal uses. 



Automatic change to mobile terminal operation. 

If the terminal could not find any signalling required for 
the battery saving protocol operation (<SVP6>), but 
detects <SVP1> required for mobile terminal operation, the 
terminal cou-ld act as mobile terminal. The user should be 
informed of this so the terminal could be switched-of f . 

The MPAK MODE is sent to the network informing that the 
terminal has gone into mobile terminal operation. 

Prevention from automatic quick channel monitoring 

In order to prevent the automatic quick channel monitoring 
from continuously running or to prevent the terminal from 
repeated attempts to go into the quick channel monitoring, 
it is recommended that the user manually can switch the 
quick channel monitoring function off. 

It is also recommended that the terminal has some kind of 
watchdog function implemented, limiting the operating time 
in quick channel monitoring mode. 



Manual initiation of quick channel monitoring 



If the hand-held terminal is implemented without automatic 
quick channel monitoring functions it is recommended that 
this function can be manually initiated. 
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User notification or 'lost contact' 



When the terminal loses contact with network, according to 
roaming procedure, and goes into quick scan monitoring the 
operator of terminal should be notified. It is also 
suitable if the received signal strength indication (RSSI) 
is displayed to the user so positioning of the terminal 
could be facilitated. 



RSSI when transmitting 

It is recommended to display the received signal strength 
to the user especially when the terminal is going to 
transmit, so the user can move the terminal to a good 
location. 
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7 MOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with the Dage(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 

Rl-06, 21 
Rl-09, 6 

Rl-16, 10, 11, 12, 13, 18 



Below are the reference designations listed. 
Section 

Arrangement of the documents 
MOBITEX System description 
General description of terminals 
Terminology 
References 

Network operator information 
Application layer 
Network layer 

Interface requirements, fixed terminals 
Other requirements, fixed terminals 
Link layer, mobile terminals 
Physical layer, mobile terminals 
Radio equipment, mobile terminals 
Other interfaces, mobile terminals 
Other requirements, mobile terminals 



Rl-01 
Rl-0 2 
Rl-03 
Rl-0 4 
Rl-0 5 
Rl-0 6 
Rl-08 
Rl-09 
Rl-11 
Rl-12 
Rl-16 
Rl-17 
Rl-18 
Rl-19 
Rl-20 
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Cantel Mobitex- 


MOBITEX 

Data Link Layer, Mobile Terminal 
8/16 kbps 



ABSTRACT 

This document specifies the data link layer for terminals 
connected to the MOBITEX network. 

The mobile terminal's Data Link Layer together with the 
Physical Layer form a radio protocol for communication 
between mobile- stations (MOB) and a base radio station 
(BASE) . 

The interchange of information between BASE and MOB is in 
the form of frames. There are 21 different types of 
frames. 

A number of different access strategies are used in the 
protocol to permit the handling of a large number of 
mobile terminals on a few trunked channels. The most 
important aspects are: 

Time slots 

Selective repetition 
Priority access 
Concurrent channels 
rr Automatic roaming. 

To achieve high transmission reliability, the frames are 
divided into blocks where each block is coded. 
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IMTRODOCTION 



The Link Layer of mobile terminals forms a link between 
the Network Layer and the physical radio channel with its 
special properties. It ensures a safe and efficient 
transmission path between the mobile terminal and the 
network, represented by the base stations. The Link Layer 
includes error correction facilities,, access algorithms, 
roaming algorithms, priority facilities etc. 



Rap* 
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2 INTERACTION WITH UPPER LAYERS 

The upper layers handle packets of information, MPAK . The 
following figure presents the general apperance of an MPAK 
(it is fully described in reference Rl-09). 



Type, status etc. 



Type-dependent 
component 



The Link- Layer transmits the MPAK in the form of 'a frame. 
The frame structure is defined in chapter FRAME STRUCTURE. 
The conversion .of a packet into a frame is described in 
APPENDIX A. 

If the Link Layer is unsuccessful in transferring an MPAK 
to the network, it is returned to the Network Layer, with 
this information. The Network Layer can then request a new 
attempt by sending the MPAK. back to the Link Layer. 
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3 FRAME STRUCTURE 



PARTS OF THE FRAME 



The transmission of digital information over the radio 
channel is performed by transmitting frames. A frame 
• comprises a limited number of bits which are transmitted 
in an uninterrupted sequence. The frame consists of the 
following parts: 



sync pattern, base identity 



) address etc. 



Parity field . 



Information field 



Parity field 



Information field 



Frame "head 
Primary block 



Following block #1 



Following block #n 



The frame head is described in detail in reference Rl-17. 
The information and parity fields of the following blocks 
are described in APPENDIX A, together with the primary 
block . 
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3.2 FRAME TYPES 



There ace 21 different frame .types: 

Name Designation 



M frame <HHM> 

Acknowledgement <ACK> 

Negative acknowledgement <NAK> 

Repetition request <REB> 

Repetition reply <RES> 

Access request, data <ABD> 

Access request, speech <ABT> 

Access request, emergency <ABL> 

Access permission, data <ATD> • 

Access permission, speech <ATT> 

Access permission, emergency <ATL> 

Change channel, data <BKD> 

-Change channel , speech <BKT> 

Free signal <FRI> 

Sweep' signal <SVP> 

Silence order <TST> 

Activity request <AKT> 

No access permission, speech <NAT> 

Change base station, speech <BBT> 

Wait for channel, speech <VKT> 

Cancel access request, speech <AAT> • 



Yes 
Yes 
Yes 
Yes 
Yes 



Yes 
Yes 
Yes 
Yes 
Yes 
Yes 
Yes 
Yes 
Yes 
Yes 
Yes 
Yes 



Yes 
Yes 
Yes 
Yes 
Yes 
Yes 
Yes 
Yes 



Exhibit 2, p. 555 



7 



Cantel Mohitex- 



9/1056 - A 296 5171/02 De 



1990-02-26 A 



The following pages give a brief description of each frame 
type. Refer to Appendix A "Frames" for a complete 
definition of frame types. 



An <MRM> is used to transfer packets (MPAKs). The 
packet formats are defined in reference Rl-09. 



2 Acknowledgement <ACK> 

An <ACK> acknowledges a correctly received frame. 

<ACK> indicates that all blocks in the frame have 
been correctly received. It includes the sequential 
number of the received frame. 



3 Negative acknowledgement <NAK> 

A <NAK> requests repetition of the entire <MRM>. 

<NAK> indicates that the primary block has been 
correctly received, but that the following blocks 
have been lost. It contains the sequential number of 
the received primary block. <NAK> results in a 
complete repetition of the lost <HRH>. 

Note that if the number of blocks in <MRM> was 3 or 
more, <REB> is used instead of <NAK>. 



Repetition request .. <REB> 

A <REB> requests repetition of erronous blocks in an 
<MRM> or <RES>. 

If it is found during reception that certain blocks 
in a frame are not correct, a request far these 
blocks to be repeated can be made by transmitting a 
<REB>. The request contains a bit map of the blocks 
to be repeated. This bit map refers to the original 
<MRM>, even during a sequence of repetitions. 

<REB> contains the sequential number of the received 
<MRH> and results in a <RES>. 

Note that if the number of blocks in <MRM> was 2 or 
less, <NAK> Is used instead of <REB>. 
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5 Repetition reply <RES> 

A <RES> is the reply to a <REB>. 

<RES> is a selective repetition of blocks from an 
<MRH>. The following blocks of the <RES> contain 
copies of blocks according to the bit map of the 
<REB>. <RES> contains the sequential number of the 
original <MRM>. 



Access request, data <ABD> 

An <ABD> is a request to transmit an <MRM>, 
containing "data" (defined in chapter "Addressing a 
mobile terminal"), whose length (number of blocks) 
exceeds the value of MAX_ACCESS. MAX_ACCESS is 
described in chapter "Time division"? 

If the length of the <MRM> exceeds MAX_ACCESS, 
access must be requested before the <HRM> may be 
sent. 



The <ABD> states the number of blocks in the 
corresponding <MRH>. 



7 Access request, speech <ABT> 

An <ABT> is a request to transmit an <MRM>, 
containing "speech" (defined in chapter "Addressing 
a mobile terminal"), containing a request for a line 
connection whose length (number of blocks) exceeds 
the value of MAX_SPEECH. MAXJSPEECH is described in 
chapter "Time division". 

If the length of an <HRM> with a connection request 
exceeds MAX_SPEECH, access must be requested before 
the <MRM> may be sent. 

The <ABT> states the number of blocks in the 
corresponding <HRH>. 
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Access request, emergency <ABL> 

An <ABL> is a request to transmit an <MRH> 
containing an "emergency" (defined in chapter 
"Addressing a mobile terminal"), whose length 
exceeds the value of MAX ACCESS. MAX_ACCESS is 
described in chapter "Time division". 

If the length of the <MSM> exceeds MAX_ACCESS, 
access must be requested before the <MRM> may bi 
sent. 

The <ABL> states the number of blocks in the 
corresponding <MRM>. 



9 Access permission, data <ATD> 

BASE replies with an <ATD> to an <ABD> from a MOB, 
when BASE is ready to accept an <MHM>. 

When permission is granted (<ATD> received), MOB is 
expected to transmit an <MRM> containing a data 
packet. 



10 Access permission, speech <ATT> 

BASE replies with an <ATT> to an <ABT> from a MOB, 
when BASE is ready to accept an <MRM>. 

When permission is granted (<ATT> received), MOB is 
expected to transmit an <MHM> containing a request 
for line connection. 



11 Access permission, emergency <ATL> 

BASE replies with an <ATL> to an <ABL> from a MOB, 
when BASE is ready to accept an <MHM>. 

When permission is granted (<ATL> received), MOB is 
expected to transmit an <MRM> containing an 
emergency signal. 
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Change channel, data <BKO> 

A <BKD> orders a MOB to another channel in order to 
transmit or receive an <MRM>, data or emergency. 

Normally the terminal returns to the original 
channel when the <MHM> has been transmitted or 
received. If an error occurs on the assigned channel 
then MOB returns to the original channel after a 
timeout period stated in the <BKD>. 



13 Change channel, speech <BKT> 

A <BKT> orders a MOB to another channel in order to 
transmit or receive an <MRH> containing a request 
for line" connection. 

Normally the terminal returns to the original 
— channel when the line connection is over. If an 
error occurs on the assigned channel then MOB 
returns to the original channel after a timeout 
period stated in the <BKT>. 



14 Free signal <FRI> ■ 

BASE transmits a <PRI> when it is ready to handle 
traffic from MOB. 

A free signal precedes a free cycle. A free cycle is 
a period of time .when all of, or parts of, the total 
fleet of mobile terminals are collectively permitted 
to transmit. 



15 Sweep signal <SVP> 

The sweep signal is a periodically recurring signal 
from BASE. An <SVP> is transmitted by BASE for two 
reasons: 

1 <SVP> marks the start of a sweep cycle. 

2 <SVP> contains system parameters, such as: 

' - time to next <SVP> 

maximum number of repetitions' 
channel list 
local system channel 
access channel 
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16 Silence order 


<TST> 



Silence order is used by BASE to withdraw all access 
permissions during a free cycle. A MOB that is 
already transmitting may continue to do so, but for 
every other MOB the access permissions for all 
traffic types- (emergency, speech and data) are 
withdrawn. 



Note i Please also refer to the description of the 

silence signal in reference Rl-17. This signal 
has the same meaning as the <TST>-frame but 
uses only the frame head and thus addresses 
ALL mobile terminals. 



17 Activity- request <AKT> 

An <AKT> is used by BASE to check whether a certain 
MOB is active. MOB replies with. an <ACK> to such ".a 
frame. 



18 No access permission, speech <NAT> 

BASE replies with <NAT> to an <ABT> from a MOB when, 
•for some reason, a line connection cannot be set up 
(e.g. no channel is available). 



19 Change base station, speech <BBT> 
BASE will use <BBT> 

- as a response to an <ABT> when another base 
station is. to be used for the line connection 

or 

- to hand over a call in progress to another base 
station. 
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Wait for channel, speech <VKT> 

If no channel is immediately available, BASE may 
place MOB in .a queue of waiting calls and reply with 
a <VKT> to a received <ABT>. When a speech channel 
becomes available, BASE indicates this by 
transmitting a <BKT> to MOB. If there is no free 
channel within reasonable time, BASE ends the 
session by transmitting a <nat>. 



21 Cancel access request, speech <AAT> 

After having received a <7KT> from BASE, the mobile 
terminal may end the session by transmitting an 
<AAT>. 
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4 TRAFFIC HANDLING 

4.1 TRANSMISSION PRINCIPLES 

Transmission is carried out through the interchange of 
frames between MOB and BASE. Different types of trans- 
mission cases demand different behaviours by the units 
involved. Some of the problems considered in this chapter 
are: 



Access to the channel 



Addressing 



Sequential numbering 



■ describes how a small number 
of channels can handle 
concurrent traffic from a 
large number of subscriptions 
at the same time. 

' describes how the mobile 
unit maintains its contact 
with the network (roaming). 

• describes how the addressing 
of base radio stations, 
terminals and subscriptions 
take place. 

• describes how repeated 
presentations of repeated 
frames are avoided. 
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4.2 ACCESS TO THE CHANNEL 
4.2.1 Time division 

A MOB, with traffic to send, is allowed to establish 
contact with the base radio station in special free 
cycles. These cycles are initiated by BASE by transmitting 
a <FRI>. 

This frame contains an indication of the length of the 
free cycle, including the following parameters: 

States the length of each individual free 
slot. 

States the total number of free slots in 
the current free cycle. 

States the interval for' the random number 
generator in the MOB. 

States the maximum length of an <MEM>- 
frarae, containing data or emergency, which 
can be sent without a preceding access 
request. 

Max_speech States the maximum length of a frame, 

containing a connection request, which can 
be sent without a preceding access 
request. 

In order to reduce the probability of a collision between 
traffic from several mobile units, the free cycle is sub- 
divided into slots. The length of these slots (Tl) are 
stated by the Slot length parameter. 



Slot_length 
Pree_slots 
Rand_slots 
Max_access 



slot n+1 slot n+2 slot n+3 



t t+Tl ~ t+2*Tl t+3*Tl" t+4*Tl~ -> * 

By the aid of an internal clock, the mobile terminal is 
able to detect slot boundaries. The definition of how slot 
boundaries are calculated is found in reference Rl-17. 
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The following happens in the free slots. 



Traffic initiated before the start of the free cycle 
must be distributed at random. A random number 
generator selects a slot between 1 and Rand_slots. 
Transmission begins at the start of the selected 
slot. 

Traffic initiated during the free cycle is sent at 
the beginning of the next slot. 

If the <HHM> to be sent is long.er than MAX_ACCESS or 
MAX_SPEECH, a request for access must be made. The 
transmission of this request is done according to 
rules 1 or 2 above. 



If the Data Link Layer is in the speech mode (ordered by 
the Network Layer), an <MRM> may be sent immediately. This 
is done independently of any free cycles. 
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4.2.2 Mobile fleet division 



The access permission in the free cycle can be given to 
parts (subsets) of. the mobile fleet according to the 
setting of corresponding fields in the free signal, <FRI>. 
This is used to reduce the number of access attempts in a 
free cycle. The following principles are used: 

Masked addressing The address and mask fields in <FRI> 
are used for. a binary division (1, 2, 
4,- B etc) of the mobile fleet. 

Priority Is used to give access only to mobile 

terminals above a stated priority 
level. 

Traffic type, FFG Is used to give access only for stated 
traffic types (emergency, data or 
speech ) . 



In the <SVP> a channel (receiving and transmitting 
frequencies) and a channel type (local system or access 
channel) can be given. By using the addressing facilities 
in the <SVF> it is possible to assign a certain system 
and/or access channel to the whole mobile fleet or to 
parts of it. 

The local system channel is used in much the same way as 
any other system channel. It is not shared by surrounding 
base stations and may thus be used without interference 
from these. 

When assigned a local system channel, the mobile terminal 
monitors this channel until further notice or the roaming 
algorithm indicates that it is no longer usable. 

When assigned an access channel, the mobile terminal must 
use this channel when it. has an <MRM> to transmit. The 
access rules described above also apply to this channel. 
After the. <MHM> has been acknowledged the terminal returns 
to the previous (local) system channel. 
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The algorithm for selection of a suitable base is called 
roaming. It is designed to handle a nationwide system of 
base radio stations on different system channels, with 
either frequency or time division in their signalling. The 
algorithm includes two methods of channel monitoring: 
- normal and quick. 

A mobile terminal measures the received signal strength 
from all base radio stations. To evaluate one base station 
the mobile terminal calculates its roaming value. The 
roaming value is defined as the average received signal 
strength. Please see reference Rl-17 for further 
information about how to measure received signal strength. 

After a <BKT> -or a <BKD> has been received, the monitoring 
is disabled. It is resumed after the connection/session is 
ended, and the same table of evaluations as before the 
connection is used. 

When the terminal is switched on, it uses the 
CURRENT_SYSTEM_CHANNEL and the CORRENT_BASE until this 
base becomes unsuitable according to the roaming 
algorithm. If no CORRENT_BASE has been stored, the 
terminal immediately starts the quick channel monitoring, 
using the default list of system channels. 



Lists of system channels 

The mobile terminal uses a list of system channels when it 
monitors the base radio stations or searches for a new 
base. It is either a permanent or a temporary default list 
(please refer to the chapter 'SYSTEM PARAMETERS TO BE 
STORED IN THE TERMINAL' and to reference Rl-06) or the 
current list (stated in the <SVP>-f rame) . 

The default list is used until a <SVP>-frame has been 
received. A <SVP>-frame with a new list of system channels 
completely overrides the old current list. 

The default list is also used in the quick channel 
monitoring after an unsuccessful search of the current 
list has been made. Again, the default list is used only 
until a valid <SVP>-frame with the current list of system 
channels has been received from the new base station. 
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Measurement methods 

When the mobile terminal measures the received signal 
strength it can use two different measurement procedures: . 
FRAME or CONTINUOUS. Which of these it should use is 
stated by the parameter RSSI_PR0C in the <SVP>-frame. 

If RSSI_prqc states FRAME the mobile terminal measures the 
received signal strength of the frame heads received 
during the RSSI_PERIOD (stated in <SVP>). 

If RSSI_PROC states CONTINUOUS the mobile terminal 
measures the received signal strength during the entire 
RSSI_PERIOD. 

The parameter RSSI_PERIOD includes channel switching time, 
and has the default value 2 960 ms, with a tolerance of 
+/- 10 ms. - 

During monitoring of current system channel and when 
making the final decision before chosing a new base, the 
terminal measures average received signal strength during 
the reception of frame heads. 
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Normal channel monitoring 

A mobile terminal measures the received signal strength 
from base radio stations on the CURRENT_SYSTEM_CHANNEL and 
calculates a roaming value for each base station. 

During each <SVP>-cycle (i.e. the time between two <SVP>- 
frames) the terminal leaves the CtIRRENT_SYSTEM CHANNEL for 
' a predefined period to monitor other channels and then 
return. These channels are chosen from the list of system 
channels (default or current). The start of the scan 
period depends on the terminal's own subscription number 
(MAN) being odd or even: 



scan start (odd) = TIME_TO_NEXT - 
scan start (even) * TIME_TO_NEXT • 



•' 2*SCAN TIME 
• SCAN TIME 



TIME_TO NEXT 



Example ; 



ch #n 

ch #4 
ch #3 
ch #2 
ch #1 



: Length of predefined scan period, including 
channel switching time. This is stated in 
the <SVP>-frame and has. the default value 3 
seconds, with a tolerance of +/- 10 ms.. 

; Interval between two <SVP>-f raiues. This 
parameter is stated in the <SVP>-frarae and 
has the default value 10 seconds. 



al ssssssssssss li 



where m = monitor current system channel 

s = scan other system channels 
r = RSSI_PERIOD 
e = evaluation 

The monitoring is cyclically repeated for all channels and 
every channel is monitored one RSSI_PERIOD. 

For example, if the RSSI_PERIOD and SCANjri-ME have default 
values, the list contains 7 channels and the length of a 
<SVP>-cycle is 10 seconds, then the time between the scans 
of a specific channel from the list is 70 seconds. On the 
other hand, if the RSSI PERIOD is 4 (80 ms) and SCAN TIME 
is 30 (3 s) then the moEile will scan at least 30 channels 
during each <SVP>-cycle. 
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Criteria for leaving CURRENT BASE 



The mobile terminal leaves CURRENT BASE during a <SVP>- 
cycle if: 

-1- roaming value ( CURRENT_BASE } < BADJ3ASE 

BAD_BASE is stated in the <SVP>-frame and its 
default value is 15. 



-2- roaming value (best base) > 

roaming value (CURRENT_BASE) + BETTER_BASE. 

If this criterion is fulfilled, the mobile should remain 
in normal channel monitoring on the current system channel 
for another <SVP>-cycle. During the next scan period the 
mobile should measure the average received signal strength 
of frame heads from best base. If the roaming value still 
fulfils the criterion, the mobile should select this base" 
as new CURRENTJBASE and the new channel as 
CURRENT_SYSTEM_CHANNEL. 

The following figure shows an example where this criterion 
applies: 

roaming value 



30 • 

BETTER_BASE | 
BAD BASE 15 ' 



CURRENT BASE 



The parameter BETTER_BASE is stated in the <SVP>- 
frame and its default value is 10. 
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The following criteria cause the mobile .to leave 
CORRENT_BASE immediately without waiting for the end of 
the <SVP>-cycle: 

-3- The terminal has made MAX_REP retransmissions 

without getting an acknowledgement from base. The 
value of MAX_REP is stated in the <SVP>-frame. 

-4- The terminal has received a <NAT> (including an 
order to leave the CURRENT_BASE) from base. 

And the last criterion applies when no traffic is 
exchanged: 

-5- The terminal has not received valid <SVP>- f rames 
within 2 <SVP>-cycles (= 2*TIME_TO_NEXT] . 



Any of the above criteria, except -2-, causes the mobile 
terminal to leave CORRENTJ3ASE and evaluate other bases.. 

Evaluation of other base stations 



MOB first evaluates the best base (j* CORRENT_8ASE) from 
the normal channel monitoring. This is done by evaluating 
the : 

roaming value from the last <SVP>-cycle (on 
CURRENTJ3 YSTEMjCHANNEL ) 

roaming value from the last RSSI_PERIOD of a 
specific channel (on the other system channels) 

If the base is on the CURRENT SXSTEM_CHANNEL and have a 
roaming value greater then GOOD_BASE~i t can be directly 
selected as CURRENT_BASE . 

But if the new base is on. a new system channel the mobile 
shall measure the average received signal strength during 
the reception of frame heads on this channel for 
SCAN_TIHE. If the measured roaming value is greater then 
GOOD BASE, the mobile should select this channel as 
CURRENT SYSTEM CHANNEL and this base as CURRENT_BASE. 
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Quick channel monitoring 

If best base is not good enough, a quicker scanning 
procedure is adopted until a suitable base is found. MOB 
then scans its list of (current) system channels in the 
following way: 

-1- Begin with the first channel from the list. 

• -2- Measure the average received signal strength for 
RSSI_PERIOD. 

-3- If the measured roaming value is greater than 

GOOD_BA.SE remain on this channel. Otherwise skip to 
step 6. 

-4- Measure the average received signal strength during 
the reception of frame heads on this channel for 
SCANJTIME. 

-5- ..If the roaming value is greater then GOOD_BASE 

select this channel as CORRENT_SYSTEM_CHANNEL , the 
base as CURRENT_BASE and return to normal channel 
monitoring. Otherwise go to step 6. 

-6- Stop scanning if all channels of the list have been 
scanned. Otherwise choose next channel from list and 
repeat steps 2-5. 

After MOB has scanned a number of channels from the list 
(please see reference Rl-06) , or the list is ended, the 
current system channel is scanned in the same manner. The 
scan of the list is then resumed, if the end of the list 
was not already reached. 

If the complete current list of system channels has been 
searched without a new base having been chosen, the quick 
channel monitoring is restarted with the default list of 
system channels ... 



Re-establishing contact 

When a new CURRENTJ3ASE has been chosen, an <MRM>-frame 
with roaming information is sent to it. If the new BASE is 
identical to the old CORRENT_BASE, an <MRM>-frame with 
activation information is sent instead. 
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Area identification 

The frame header (on the physical layer) includes an area 
identification used to specify geographical areas. Such an 
area is denoted as a traffic area and is given a unique 
area ID by the network. 

From the network layer, the data link layer receives a 
list including the areas subscribed to by the user. The 
list also shows if the areas not subscribed to are allowed 
to be used, with for example higher charges, or not. 

Prom the physical layer, the data link layer receives 
information about incoming roam information, i.e. area ID, 
base ID and weighted roaming value. 

During the roaming procedure (described above), the 
terminal will 'primarily evaluate roaming information from 
bases belonging to the subscribed traffic areas. If the 
terminal is allowed to traffic other areas all bases may 
—be considered in the roaming procedure. — . 

In case a "non-subscribed" base is chosen (possible only 
in quick channel monitoring), it should be notified to the 
application layer, as well as when the terminal returns to 
a "subscribed" base. 

If the terminal have not yet received the list of area 
IDs, the roaming procedure will evaluate all base 
stations. 
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4 . 4 ADDRESSING 



4.4.1 Addressing the base radio station 

The base radio station is only addressed in the frame 
head. Further details can be found in reference Rl-17. 



4.4.2 Addressing a mobile terminal 

Transmitting The mobile terminal's, subscription number 
(MAN) is always used as the MOB address. 

Receiving When receiving, the MOB address refers to 

the mobile terminal's MAN, or any MAN 
representing a group to which the terminal 
- belongs. (A transferred subscription is 
addressed in the MPAK. ) 

— A MAN-repr-esenting a group occurs only 

when receiving frame types <MRM>, <BKD>, 
<BKT>, <BBT> and together with a mask 
value of 0 in frame types <PRI>, <SVP>, 
<TST>. Masked addressing is described in 
detail in chapter 4.4.2.1. 

Masked and priority addressing is used in 
frame types <SVP> and <TST>. 



Masked, priority and traffic type 
addressing is used in frame type <FRI>. 
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4.4.2.1 Masked addressing. 

Masked addressing is only used in <SVP>, <FRI> and <TST>. 
In this addressing mode both the MASK and MOB fields of 
the frame are used. The MASK field indicates the number of 
bits from the beginning of the MOB field (most significant 
bits) that should not be considered (masked out) when 
comparing the MOB field with the terminal's MAN. 

A MASK value different fromO (zero) indicates that only 
the terminal's own MAN is to be compared with the relevant 
bits of the MOB field. 

A MASK value of 0 (no bits masked out, all bits of MOB are 
relevant) indicates that the MOB field is to be compared 
with both the terminal subscription MAN and with the MANs 
of all current group numbers in the group list. 

The terminal is considered to be addressed if all relevant 
bits of the MOB field are the same as the corresponding 
.-bits of-^one of the compared MANs. 

A MASK value of 24 (decimal) .indicates that all bits are 
masked out and that all mobile terminals are addressed. 

Note: For <SVP> and <TST> signals the priority of the 

terminal must also comply with that of the signal. 

■For the <FRI> signal the priority and traffic type 
of the terminal must comply with that of the signal 
for the terminal to be addressed (except for 
emergency where priority is ignored) . 
(See below) . 
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Example : Assume a frame with the following contents in the 
HOB and MASK fields. 

(x indicates that the corresponding bit is to be 
ignored) 

MOB field Bit no. : 1 ■ * 4 

■ : Value : 101000000000101010110010 



11000 (24 decimal) 



All mobile terminals are addressed. 



: field Bit no. : 15 

• Value : 10111. (23 decimal). 



Only mobile terminal subscriptions with MAN 
ending with binary 0 are addressed. 



10110 (22 decimal) 



Only mobile terminal subscriptions with MAN 
ending with binary 10 are addressed. 



: field Bit no. : 15 

Value : 00000 (0 decimal) 

Addressed MAN Bit no.: 1 24 
Value : 101000000000101010110010 

The MASK value 00000 (zero) indicates that 
mobile terminals with the terminal 
subscription MAN, or any of its MAH numbers 
representing groups, identical to the MOB 
field are addressed. 
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4.4.2.2 Priority addressing 

Priority addressing is used in the frames <SVP>, <TST> and 
<FRI> . 

A terminal subscrir>tion belongs to one of 4 priority 
groups. The terminal may have two priority states within 
each group, normal or raised. The terminal will raise its 
priority if it has made MAX_REP retransmissions of the 
same frame without getting any acknowledgement from the 
base station. 



PRIO field Meaning 



7 


111 


Priority group 4, 


raised priority 


6 


110 




normal 


5 


101 


Priority group 3, 


raised priority 


4 


100 




normal 


3 


011 


• Priority group 2, 


raised priority 


2 


010 


normal 


1 


001 


Priority group 1, 


raised priority 


0 


000 


: normal 



When receiving a frame with priority addressing, the 
mobile terminal is addressed if its own priority is higher 
than or same as the received priority. 

If the terminal is to transmit an emergency signal the 
priority level is ignored. 
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4.4.2.3 Traffic type addressing 

Traffic type apnlies to the type of MPAK to be sent from 
the mobile terminal. The packets are separated into 3 
traffic types: 

emergency: MPAK class PSOSCOM 

speech: MPAK class CSDBCOW 

data: All other types of MPAK 



Traffic type addressing is used only in the <FRI> frame. 
The traffic type to which the <FRI> applies is coded into 
the FFG field as follows: 



Value 


Emerqency 


Speech 


Data 


00 


yes 


no 


no 


01 




no 


yes 


10 


yes 


yes 


no 


ir 


ves 


yes 


yes 



Note: For the frames <SVP> and <TST>, both the masked 
address and the priority must be correct for the 
terminal to be addressed. 

For the <FRI> to be valid, the masked address, the 
priority and the traffic type criteria must be met 
by the terminal, except for the transmission of an 
emergency signal where only the masked address and 
traffic type criteria has to be met (priority is 
ignored) . 
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4.5 SEQUENTIAL NUMBERING 

The transmitting unit reDeats the transmission of a frame 
if there is no response from the receiving unit. This 
means that the receiving unit can receive identical frames 
if its resDonse is not detected by the transmitting unit. 
To avoid repeated presentation of information, certain 
types of frame are given sequential numbers. The principle 
is as follows. 

The terminal sets up a sequential register for the 
terminal subscription MAN (up and down sequential 
number) and for each of the MANs stored in 
GROUP LIST (only a down sequential number for each). 

A sequential number is an integer with a value in 
the range (0...15). The sequential numbers are 
incremented cyclically 1, 2, 3...., 14, 1, 2, 3 etc. 
The values 0 and 15 are reserved for special 
purposes. 

- The ulT^e r que'htiaT number applies to frames 

transmitted in the direction from MOB to BASE. The 
up sequential number is increased by one by the 
mobile terminal for each new <MRM>-frame 
transmitted. 

MOB which receives a sequentially numbered frame 
checks the sequential number of the frame against 
the stored down sequential number for the 
corresponding MAN. If the received sequential number 
is the same (and not 0, see below), the information 
in the frame is ignored. If the sequential number is 
not the same (or 0, see below), the frame is 
accepted and the sequential number of the received 
frame is stored (except for 15, se below). The 
number is stored when acknowledgement of the frame 
has been sent. 

On reception, the value 0 for a sequential number 
means that a sequential number check should not be 
carried out on the frame and that the value 0 should 
be stored "in the terminal as the new down sequential 
number . 

On reception, the value 15 for a sequential number 
means that a sequential number check should not be 
carried out on the frame and that the old down 
sequential number remains. 
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The up and down sequential numbers are set to 0 when not 
defined (e.g. at initial start up). 

Down sequential numbers for group numbers are reset to 0 
when roaming in on a new base station. 

Also returned packets with status UNKNOWN should have a 
sequential number. 

When the mobile is transmitting the following types of 
packets, the sequential number 15 should be used: 

CSUBCOM:DISCON 

CONREA 
DTESERV : ACTIVE 

INACTIVE 

ROAM 

BORN 
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4.6 OUTPUT POWER CONTROL 

The MOBITEX system allows for mobile terminals to control 
the output power via Darameters in the system signalling, 
from the base radio' station. Network operator requirements 
concerning this matter is stated in reference Rl-06, as 
well as the nominal output power. 

Requirements, such as the number of output levels to be 
controlled by the mobile terminal and in what steps the 
levels should be controlled, is also stated in reference 
Rl-06. 

The mobile terminal receives information about the output 
power to be used in the base station cell in question. 
This is stated by the parameter TXPOW in the <sVP>-frame. 

Portable transmitters may have lower output power than 
ordinary transmitters. Note that the receiver sensitivity 
should be reduced or an offset should be added to the 
parameters GOOD BASE and BAD_BASE used in the roaming 
procedure. This~is done in order to keep the same ratio 
between the permitted transmission losses in the send and 
receive directions, i.e. to maintain a balanced radio 
path. 

For example, if the power of the transmitter is 10 dB 
lower than the specified level, the receiver sensitivity 
could be reduced by 10 dB from the specified sensitivity 
level. Instead of reducing the sensitivity, an offset of 
10 can be added to the parameters GOODJBASE and BAD_BASE. 



Exhibit 2, p. 



Cantel Mobitex" 



9/1056 - A 296 5171/02 De 



1990-02-26 A 



4.7 LOGICAL DESCRIPTION 

The data flow diagram below shows the interaction between 
modules in the Data Link Layer and between this layer and 
the Network and Physical Layers. 



[Application Layer] | Network Layer j 




L 8 ' 


L 1 


2 










Packet handling 


(PAHA) 


1 



Processing -in- 
coming frames 
(IFRA) 



Processing out- 
going frames 
(OFRA) 



Input and 
decoding- (DCOD) 



Coding and 
output (CODE) 



Base contact 
monitoring' 
(BMON) 



Physical Layer 



-1- MPAK transmitted, MPAK not transmitted, HPAK received, 

roaming, activation 
-2- MPAK to transmit, MPAK to retransmit, speech on, 

speech off, order to return MPAK, list of area IDs, 

list of group numbers 

Signals to/from Physical Layer: 

-3- Received block, Sync search 
-4- Frame to send, Frame length 

-5- Slot length, Chosen slot. Slot reached, Silence, 

Cannot send 
-6- Current base, Frame sent 
-7- Received base, Measure_RSSI, RSSIjneasured 

Signals to the Application Layer: 

-8- Speech queue info, base lost, base contact, area 
subscribed to chosen, area not subscribed to chosen 
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4.7.1 Input and decoding (DCOD ) 

DCOD converts the bit stream from the physical layer into 
frames. It decodes the blocks of these frames and checks 
that the frames are addressed to the terminal. 



4.7.1.1 Logical description 



wait for information bits from Physical Layer 
read and decode first block 
IP first block is correct THEN 
CASE frame type 

WHEN <ACK> , <HAK> , <ATL> , <ATD> , <ATT> , £NAT > or <VKT> 
IF frame address terminal address THEN 

send frame to OPRA 
ENDIF 

WHEN <REB> 

IP. frame address = terminal address THEN 
read and decode remaining blocks of frame 
IF frame is error-free THEN 

send frame to OFRA 
ENDIF 
ENDIF 

WHEN <FRI>, <SVP> or <TST> 

IP (frame address with mask = terminal address) OR 
{mask=0 and address = a group address) -THEN 
read and decode remaining blocks of frame 
IF frame is error-free THEN 

send frame to OFRA 
ENDIF 
ENDIF 

WHEN <AKT> or <RES> 

IP frame address = terminal address THEN 

read and decode remaining blocks of frame 

send frame to IFRA 
ENDIF 

WHEN <HRH>, <BKD>, <BKT> or <BBT> 

IF (frame address" = terminal address) OR 
(frame address = a group address) THEN 
read and decode remaining blocks of frame 
send frame to IFRA 
ENDIF 
ENDCASE 
ENDIF 

send sync_search order to Physical Layer 
ENDLOOP 
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4.7.2 Processing incoming frames (IFRA) 




IFHA handles the received frames from DCODi If a received 
<MRM> is not errorrfree, IFHA requests a repeat 
transmission of the faulty blocks until a correct <MRM> 
has been received and acknowledged. 




4.7.2.1 Logical description 




wait for frame from DCOD 
CASE frame type 
WHEN <HRM> 




delete a that M <MRM> aitin9 " ^ 
ENDIF 

IP response required THEN 
IF <MRM> is error-free THEN 

send <MRM> to- 5 AHA 
ELSE 




IP <MRM> is shorter .than 3 blocks THEN 
create <NAK> and send it to CODE 




ELSE 

create <REB> and send it to CODE 
store <MRM> while waiting for <RES> 
ENDIF 




ELSE 

IP <MRM> is error free THEN 
send <HRM> to PAHA 

ENDIF 




ENDIF 
WHEN <RES> 

retrieve stored <MHM> 

IF sequential number = stored <HRM>:s sequential 

number THEN 
complete <MRM> with error free blocks from <RES> 
IP <MRM> is error free THEN 

create <ACK> and send it to CODE 

send <MRM> to PAHA 
ELSE 




create <REB> and send it to CODE 
store <MRM> while waiting for <RES> 
ENDIF 
ENDIF 




WHEN <BKT>, <BKD> or <BBT> 
IF frame is error free THEN 
' send frame to PAHA 
ENDIF 




VMutN <AKT> 

create <ACK> and send 


it to CODE 




ENDCASE 
ENDLOOP 
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4.7.3 Processing outgoing frames (OFRA) 

OFRA handles the sending of frames. It must wait for 
permission to send,, decide whether an access request is to 
be sent first etc. 

OFRA receives <MHM>-f rames of traffic types emergency, 
speech or data from PAHA. It returns them co PAHA with a 
statement of whether acknowledgement of the frame has been 
received or not. PAHA can also request that OFRA should' 
cease trying to transfer the frame. 

If the Data Link Layer is in speech_mode, an <MRM> may be 
sent immediately. This is done with a timeout that is 
independent of any free cycles. 

OFRA is capable of handling only one <MRM>- frame at a 
time. 



.4.7.3.1 Logical description. 
LOOP 

wait for input signal 

CASE input signal 

WHEN new <MRM> from PAHA 

IF (free cycle is running) and {priority and traffic 
type allows transmission) THEN 
choose next free slot 

store <MRM> while waiting for slot_reached 
ELSE 

IF speechjnode THEN 

send copy of <MRM> to CODE for transmission 

speech mode timer := 2 seconds 
ELSE 

store <MRM> while waiting for permission to send 
ENDIF 
ENDIF 

cancel_request := FALSE 

WHEN STOP_SEND from PAHA 

return <MRM> to PAHA with status 'discontinued' 

IF speech_queue THEN 

IF free cycle is running THEN 

choose next free slot 
ENDIF 

speech_queue := FALSE 
cancel_request := TRUE 
ENDIF 

WHEN SPEECH_TROE from PAHA 
speechjnode := TRUE 
speech~queue := FALSE 

WHEN SPEECH_FALSE from PAHA 
speechjnode := FALSE 
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WHEN timeout of speech_mode_timer ^ - le< j< 




WHEN <ACK> from DCOD 

IF sequential number in <ACK> = sequential number in 
latest <MRM> THEN 
return <MHH> to PAHA with status 'OK' 
disable speech mode timer 
ENDIF 




WHEN <NAK> from DCOD 

IF sequential number in <NAK> = sequential number in 
latest <MRM> THEN 
send copy of latest <MRM> to CODE for transmission 
. ENDIF 




WHEN <REB> from DCOD 

IF sequential number in <REB> = sequential number in 
latest <MRM> THEN 
create <RES> and send it. Jo -CODE for .transmission 
ENDIF 




WHEN <FRI> from DCOD 

update free signal parameters 

IF we have <MRM> waiting for <RES> THEN 

delete that <MHM> 
ENDIF 

IF cancel_request THEN 
choose a~random free slot 




ELSE 

IF we have <MRM> to send THEN 

IF priority and traffic type allows transmission 




THEN 

IF NOT speech queue THEN 

IF we have already repeated <MRM> MAX_REP 
times THEN 
return <MRM> to PAHA with status 'failed' 




choose a 
store <HI 
ENDIF 
ENDIF 


random free slot 

IM> while waiting for slot_reached 




ELSE 

store <MRM> while waiting for permission to send 
ENDIF 
ENDIF 
ENDIF 
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WHEN <ATD> from DCOD 

IP we have data <MRM> to send THEN 

send copy of <MHM> to CODE for transmission 
ENDIP 

WHEN <ATT> from DCOD 

IF we have speech <MRM> to send THEN 

send copy of <MRM> to CODE for transmission 
END IF 



WHEN <NAT> from DCOD 

IP we have speech <MRM> to send T HEN 
IF order to leave CURRENT_BASE ' THEN 

return- <MRM> to PAHA with status 'failed' 

return <MRM> to PAHA with status 'no channel' 
ENDIP 
END IF 

speech_queue := FALSE 

WHEN.. .. <ATL>_ from. DCOD 

IF we have emergency <MRM> to send THEN 

send copy of <MRM> to CODE for transmission 
ENDIP 

WHEN <SVP> from DCOD 

IF (sub type 1 or 2) and (priority is the same as or 
less than terminal priority) THEN 
send <SVP> to PAHA 
ENDIP 



WHEN <TST> from DCOD . 
send signal to Physical Layer that we cannot_send in 
any slot 

WHEN <VKT> from DCOD 
speech_queue := TRUE 
queue timer := timeout value 

send signal SPEECH_QUEOE_INF0 to Application Layer 

WHEN timeout of queue^timer 
speech_queue := FALSE 

WHEN SILENCE from Physical Layer 

send signal to Physical Layer that we cannot_send in 
any slot 
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WHEN SLOT_REACHED from Physi cal Layer 
IF we have <MHM> to send THEN 
CASE <MRH> traffic type 
WHEN emergency 

IF <MRM> contains more blocks than MAX_ACCESS 
THEN 

create <ABL> and send to CODE for transmission 
ELSE 

send copy of <MRM> to CODE for transmission 
ENDIF 
WHEN speech 

IF cancel_request THEN 

cancel_riquest := FALSE 

create <AAT> and send to CODE for transmission 

IF <HRM> with line connection request THEN 
IF <MRM> contains more blocks than MAX_SPEECH 
THEN 

create <ABT> and send to CODE for 
transmission 

send copy of <MRM> to CODE for transmission 
ENDIF 
ELSE 

send copy of <MRM> to CODE for transmission 
ENDIF 
ENDIF 

IF <MRM> contains more blocks than MAX_ACCESS 
THEN 

create <ABD> and send to CODE for transmission 
ELSE 

send copy of <MRM> to CODE for transmission 
ENDIF 
ENDCASE 

increment counter of .attempts to send 
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4.7.4 Coding and readout (CODE ) 

CODE codes the blocks of the frame and transfers the bits 
to the Physical Layer. 



4.7.4.1 Logical description 
LOOP 

Wait for frame to transmit 
Code the blocks of the frame 
Transfer the bits to the Physical Layer 
ENDLOOP 
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4.7.5 Base contact monitoring (BMON ) 

BMON monitors contact with the base station(s) and works 
in 3 different modes: 

-1- Normal Channel Monitoring 

-2- Quick Channel Monitoring 

-3- Disabled 

For further information, see chapter ROAMING. 

Input signals come from the Physical Layer and from PAHA: 



-1- no_base_contact 
best_BASE 

-2- set_mode_l 
set_mode_2 
set_mode_3- 

-3- received base 



Physical 
Layer 
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4.7.6 Packet handling (PAHA ) 

PAHA handles the conversion between MPAKs and <mrm>- 
frames. It supervises the contact with BASE and informs 
the network when changing BASE and when returning after 
lost contact with the network. 

PAHA is only capable of handling one MPAK at a time and : 
works in three different modes: 



Normal mode - Contact with a base station is 

established and the Network Layer may 
send and receive ail types of MPAK. 

Speech mode - PAHA enters this mode only on order 

from the Network Layer. The Network 
Layer also decides which MPAKs that may 
be sent. PAHA leaves the speech mode on 
order from the Network Layer or when 
the transmission of an <MRM> has 
failed. 



Base search mode - When base contact is lost, PAHA enters 
base search mode. MPAKs from the 
Network Layer are not handled in. this 
mode. When a base has been located, 
PAHA returns to normal mode. 

The mobile terminal returns to the relevant system channel 
after the end of all sessions on other channels 
(channel_for_sending_speech, channel_for_sending_data) . 
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Logical description, main program 



IF 

st.._ __ 

system_channel 

OFRA_scatus 

main_mode 

ELSE 

main_mode 

ENDIF 



:= current_syscem_cn< 

:= free . 

:= norraal_mode 

:= base search mode 



LOOP 

CASE main_mode 
WHEN . normaljraode 

normal 
WHEN speech_mode 

speech *~ 
WHEN base_search_mode 
base search ~" 



EKDLOOP 
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4.7.6.2 Logical description, normal (norraaljnode) 

WHILE main mode = liormaljnode 
wait for Input signal 
CASE input signal 

WHEN MPAKJTO TRANSMIT from Network Layer 
create <MRM> with new up se quen tial number 
IP access channel opened THEN 
change to access channel 
channel := channel for sending_data 
ENDIF 

send <MRM> to OFRA 
OFRA_status := busy . 

WHEN MP-AK TO_RETRANSMIT from Network Layer 
create <MRM> with old up se quen tial number 
IT access channel opened THEN 
change to access channel 
channel := channel_for_sending_data 
ENDIF 

send <HRM> to OFRA 
OFRA_status := busy 

WHEN SPEECHJDN from Network Layer 
raainjnade := speechjnode 

WHEN R£TORN_MPAK from Network Layer 
send stop_send to OFRA 
wait to get frame that was in progress 
return <MRM> to Network Layer with status 'not 
transmitted' 

WHEN <SVP> from OFRA 
CASE sub type 
WHEN 1 

upd ate parameters 
WHEN 2 

CASE type of channel 
WHEN local system channel opened 
system_channel := local 
change to new system channel 
WHEN local system channel closed 
system_channel := previous 
change to new system channel 
WHEN access channel opened 

store access channel 
WHEN access channel closed 
delete access channel 
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WHEN <BKT> from IFRA 

IP acknowledgement of <MRM> THEN 

send <ACK> to OFRA 
ELSE 

start timer with timeout value 
ENDIF 

channel := channel_for_speech 
change to designated channel 
send set_mode_3 to BMON 

WHEN <BKD> from IFRA 

IF it is a channel change to send frame THEN 

channel := channel_for sending_data 
ELSE 

channel := channel for receiving data 
ENDIF 

start timer with timeout value 
change to -designated channel 
send set_mode_3 to BMON 

WHEN timeout for change of channel 
change to system_channel 
send set_mode_l to BMON 

WHEN <BBT> from IFRA 

store new parameters and change channel 

WHEN <MRM> with status 'OK' from OFRA 
OFRA status := free 

return MPAK to Network Layer with status 'transmitted' 

priority := normal 

IP channel = channel_for_sending_data THEN 

change to systera_channeT 

send set_mode_l to BMON 
ENDIF 

reset timer for change .of channel 

WHEN <MRM> with status 'failed', from OFRA 
OFRA status := free . 

return MPAK to Network Layer with status 'not 

transmitted 1 

priority := raised 

main_mode := base_search mode 

reset timer for cEange 6E channel 

WHEN <MRM> with status 'no channel' from OFRA 
OFRA_status := free 

return MPAK to Network Layer with status 'not 

transmitted' 

priority := raised 

reset timer for change of channel 
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WHEN incoming <MRM> from IFRA 
CASE incoming sequential number 
WHEN 0 




check ak := TRUE 
store~"riew down sequential number 
WEEN 15 

check_ok := TRUE 

IP different from last seq. number received THEN 
check_ok := TRUE _ ^ ^ 




ELSE 

check ok := FALSE 
ENDIF 




iswuCASK 

IF check ok THEN 

IF channel = channel_for_receiving_data THEN 
IF response NOT required THEN 
change to system_channel 
send set_raode_l to BMON 


- 


. ENDIF 

send MPAK to Network Layer . 




ELSE 

delete <MRM> 
ENDIF 

reset timer for change of channel 




WHEN Frame sent from Physical Layer 
IF frame = <ACK> THEN 

IF channel = channel_f or_receiving_data THEN 
change to system_channel 
send set mode 1 to BMON 




ENDIF 

reset timer for change of channel 
ENDIF 




WHEN no base contact from BMON 
IF OFRA status = busy THEN 

send stop send to OFRA 

wait to get frame that was in progress 

return <MRM> to Network Layer with status 'not 

transmitted' 
ENDIF 

raainjnode :~ base_search_mode 




ENDCASE input signal 
ENDWHILE 
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4.7.6.3 Logical description, base search (base search 
mode) 

wait for input signal BEST_BASE from BMON 
IF roaming value > GOOD_BASE THEN 

CURRENT_3 AS E := new base 

CORRENT_SYSTEM_CHANNEL := new channel 

send signal ROAMING to Network Layer 

clear sequential numbers for all groups 

delete access channel 
ELSE 

send signal BASE_L0ST to Application Layer 
send order set mode 2 to BMON 



wait for input signal BEST_BASE' from BMON 
UNTIL roaming value > CHOOSE_BASE 
IP base = CURRENTJ3ASE THEN 

send signal ACTIVATION to Network Layer 
ELSE 

CURRENT_BASE := new base 

CURRENT_SYSTEM_CHANNEL i= new channel, 
send signal ROAMING to Network Layer 
clear sequential numbers for all groups 
delete access channel 
ENDIF 

send signal BASE_CONTACT to Application Layer 
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Logical description, speech (speech mode) 



send speech_true to OFRA 

WHILE mainjnode = speechjnode 

CASE input signal 

WHEN speech_off from Network Layer 

wait 0.5 seconds 

change to system_channel 

send set_raode_l to BMON 

send speech_false to OFRA 

raain_raode := normal_mode 

WHEN new MPAK from Network Layer 

create <MRM> with new up sequential number 
send <MKM> to OFRA 
OFRA_status := busy 

-WHEN MPAK from Network Layer to be retransmitted 
create <MRM> with old up sequential number 
send <MRM> to OFRA 
OFRA_status : = busy 

WHEN <MRM> with status 'OK' from OFRA 
OFRA_status := free 
IF <MRM> with CSUBCOMrDISCON THEN 

change to system_channel 

send set_mode_l to BMON 

send speech_false to OFRA 

m ainjmode := normal_mode 
ENDIF 

return MPAK to Network Layer with status 'transmitted' 

WHEN <MRM> with status 'failed' from OFRA 
change to system channel 
send set_mode_l to BMON 
send speech_false to. OFRA 
mainjnode := normal_mode 
IF <MRM> with CSUBC0M:DISC0N THEN 

send <MRM> to OFRA 
ELSE 

OFRA_status := free 

return MPAK to Network Layer with status 'not 
transmitted' 
ENDIF 

WHEN <BBT> from IFRA 

store new parameters and change channel 
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WHEN incoming <MSM> from IFRA 
CASE, incoming sequential number 
WHEN 0 

send MPAK to Network Layer 
store new down sequential number 
WHEN 15 

send MPAK to Network Layer 
WHEN OTHERWISE 

IF different from last seq. number received THEN 
send MPAK to Network Layer 
store new down sequential number 

delete <MRM> 
ENDIF 
ENDCASE 

WHEN signal from BMON 

ignore this signal 
ENDCASE 
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4.B TRANSFER EXAMPLES 



This chapter describes the most 
the protocol. 



common transfer cases of 



4.8.1 Transfer without response 

Transfer without response can only take place in the 
direction BASE to HOB. 

In traffic to mobile tenninal(s) BASE often addresses more 
than one MOB. This can apply to traffic to group numbers 
or frames where masked addressing occurs. In these cases 
MOB will not transmit a response. BASE states this by not 
setting the response flag in these frames. 



Ex 1;1 



Transfer without response, <MRM> BASE — > MOB 

BASE <MRM> 
MOB 
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4.8.2 Transfer with simple acknowledgement 



BASE has full control over the down frequency and can 
transmit an <MRM>-frame at any time to a certain MOB. If 
the response flag is set and no incorrigible bit error has 
been detected in the frame, MOB should reply with <ACK>. 



Transfer with resnonse, <MRM> BASE — > MOB 



Transfer with response, <MRM> MOB ■ 



By transmitting <FRI>, BASE allows MOB to transmit <MHM>. 

In this case MOB expects an acknowledgement from BASE. The 
lack of an acknowledgement is indicated in this case by 
MOB receiving a <FRI> without having previously received 
acknowledgement of its frame. Frame repetition follows in 
this case. 

Free slots is defined, and thus access permission to the 
up channel is granted, when BASE transmits a <FRI> with an 
address that is applicable to MOB. Access permission is 
withdrawn for a certain MOB if any of the following cases 
arise. 

1 BASE transmits a silence signal (see reference 
Rl-17). This signal applies to all terminals. 

2 BASE transmits a <TST> with an address which applies 
to MOB. 

3 The free-cycle period as defined in the <FRI>- signal 
expires. 
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4.8.3 Transfer with block repetition 



If the receiver of -an <MRM> detects that one or more of 
the following blocks is incorrigible, the receiver may 
request repetition of these blocks with a <REB>. The 
sender replies with a <RES>. 

NOTE Block repetition occurs only on <MRM>- frames where 
the number of blocks is 3 or more. 




The principle described in the figure above applies in the 
direction to BASE and in the direction to MOB. 
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4.8.4 Transfer with frame repetition 

Frame repetition can occur for three reasons: 

1 The receiving unit transmits a <NAK> 

2 The receiving unit does not transmit a response 

3 The packet type results in frame repetition 

EX 4.1 



Transfer with negative acknowledgement MOB > BASE 

<ACK> 



-> t 



If the receiving unit finds that the received frame is 
incorrectable and is less than 3 blocks, it can notify the 
sender unit by transmitting a <NAK>. The transmitting unit 
should then repeat the message. The principle above 
applies in both transmission directions. 

The frame is- repeated immediately after an <NAK> is 
received, regardless of slot boundaries. 



Transfer with frame repeat, HOB > BASE 

BASE <FRI> <ACK> <FRI> <ACK> 

MOB <MRM> <MRM> 

xxxxx > t 



In this example the first acknowledgement from BASE is 
destroyed by interference so that MOB retransmits the same 
message after the next free signal. 
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Transfer with frame repeat, BASE — 
BASE < MRM > <HRM> 



In this example, frame repeat is caused by the packet type 
demanding repeated transmission. The response flag is 
never set in this case. 

This case occurs for MPAK to group numbers. To avoid 
repeated presentation of the information in the frame, the 
frame has got a sequential number. According to the 
principles for sequential numbering, MOB will ignore 
subsequent identical frames. 

NOTEl At the restart of a base radio station, the 

sequential numbers for all groups are set to 0. This 
is done to ensure that mobiles will not loose the 
first message to a group. The consequence of this 
action will be that the first' message may be 
presented MAX REP + 1 times at the- mobile terminal. 
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Transfer with access request 



If an <MRM>-frame to be sent from MOB to BASE is longer 
than MAX_ACCESS this <MRM> may not he sent during free 
slots. These longer frames are handled with access 
request, <ABD>, and access permission, <ATD>. 




The principle is that instead of MOB transmitting its 
<MRM>-frame, it transmits an <ABD>-frame. The reply to. 
this request is an access permission, <ATD> . When MOB 
receives access permission, it immediately starts 
transmitting the <MRM>. 



Repetition with max_rep, mob — > l 

BASE <FRI> . ,<FHI> . ...<FRI> 

MOB <ABD> <ABD> I 



tl: When the number of transmitted access requests is 

equal to MAX REP+1 and another <FRI> is received, the 
MPAK is returned to the network layer and a new base 
is chosen. 
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Transfer with line connection 



The line connection session is described in reference 
Rl-09. When MOB wants to send an <MRM> (containing a 
request for a line connection) longer than MAX_SPE£CH it 
must request access for this. The access request results 
in a channel change order. On the new channel the session 
for frames takes place to establish the line connection. 
When the line connection is concluded MOB returns to the 
system channel. 



Transfer with line connection 
<BKT> 



BASE cl <FRI> 
BASE c2 

MOB Cl <ABT> 
MOB C2 



<ATT> <ACK> 
<MRM> 



tl: Disable roaming and start timeout with time from 

<BKT> . 
t2: Stop timeout. 

t3: Speech_on received from Network liayer. 
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4.8.7 Transfer on several channels 

Transfer on several, channels can be divided into two 
separate cases: 

1 MOB apoears on another channel because BASE has 
stated* in a <SVP>-frarae that all traffic from a 
mobile terminal shall be sent on a channel other 
than that on which the <SVP> came. 

2 BASE transmits a <BKD>-frame as .a reply to an <ABD>. 



Transfer on several channels 
<BKD> 



BASE cl <PRI> 
BASE c2 

MOB cl <ABD> 
MOB c2 . 



<ATD> <ACK> 
<MRM> 



tl: Disable roaming and start timeout with time from • 
<BKD> . 

t2: Return to system channel, enable roaming. 



In this example, the access request from MOB resulted in a 
channel change order. The access permission is transmitted 
on channel c2. After haying received an acknowledgement, 
MOB returns to channel cl. 
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4.8.8 Line connection with hand over 



Ordinary line connection 

BASEl,cl <FRI> <BKT> 

BASEl,c2 <ATT> <ACK> 

MOB, cl <ABT> 

MOB, c2 CONREQ 



. . . speech 
. . . speech 



tl: Ordinary connection established. 



Continued with <BBT> 



BASE2,cl 
BASE2,c3 
BASEl,cl 
BASEl,c2 .. 
MOB, cl 
MOB, c2 .. 



Hand over to base B2. 

MOB connected to base B2 on new speech channel, new 
system channel stored for later use. 



t5: Connection ended. 
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4.8.9 Line connection with queue handling . 



If no speech channel is immediately available, BASE 
may place MOB in a queue of callers and reply with 
<VKT>. 



Succesfully established line connection 
BASE1,C1 <FRI> <VKT> ... <BKT> 

BASEl,c2 <ATT> <ACK> speech 

HOB, cl <ABT> 

MOB, c2 CONREQ • speech 



tl-t2: Waiting time. 

t3: Connection established. 



Call attempt ended by BASE 



tl-t2: Waiting time. 

t3: Call attempt ended. 



Call attempt ended by 1 



BASEl,cl <FRI> <VKT> 
MOB, cl <ABT> I , 



tl-t2: Waiting time. 

t3: Call attempt ended. 
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Call attempt ended by MOB 

BASE1 , cl <PRI> <VKT> I ... I <VKT> j 
MOB, Cl <ABT> I... I I 



tl-t2s Waiting time. 
t3-t4: Waiting time. 
tS: Call attempt ended. 



_ >t 
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4.8.10 Line connection without access request 



When MOB wants to send an <MRM> (containing a 
request for a line connection! shorter than or equal 
to MAX_SPEECH no access request is needed. 

The response to the <MSM> is a channel change order 
that includes an acknowledgement . The line 
connection is immediately established on the new 
channel. 



Line connection without access request 
<BKT> 



BASE cl <FRI> 
BASE c2 

MOB cl <MRM> 
MOB c2 



speech 
speech 



4.8.11 Ending a line connection 



An <MRM> with a DISCON may be transmitted only once 
on the speech channel. If MOB have not received 
<ACK> within 2 seconds, it changes to the system 
channel and continues the transmission attempts 
according to the usual rules. 



Ending a line connection 
BASE cl 

base c2 . .speech 



<FRI> <ACK> 
DISCON 
tl t2 1 



tl-t2: Timeout. 

t2: ' Return to system_channel, enable roaming. 
t3: Connection endedT 
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4.8.12 Line connection ended by speech off 



After the mobile terminal has received an <MRM> 
containing a line connection request, the session 
may be put to an end by the signal speech_off from 
the network layer. ?his signal is generated by a 
timeout (please see reference Rl-09) when che 
operator has not answered the call. 



Connection ended by signal speech_off 



BASE cl <BKT> 
BASE C2 
MOB Cl 
MOB c2 



tl: Disable roaming and start timeout with time from 

<BKT>. 
t2: Stop timeout. 

t3: Speech_off received from Network Layer. Return -to 
system channel and enable roaming; 
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5 SYSTEM PARAMETERS TO BE STORED IN THE TERMINAL 

Certain svstem parameters are stored continuously (even if 
the terminal is powered off) in HOB to permit correct 
action whan starting up. These are: 

The terminal subscription MAN 

Group number list , (GROUP LIST 

Maximum number of retransmissions allowed ( MAX_REP ) 
Sequential numbers - terminal MAN (up/down) 
Current base 
Current system channel 

A list of the area identifications that the mobile 
is allowed to use. Please see reference Rl-06. 

When switched on, all these parameters apply until a frame 
is received containing the current parameter values. 

There is also a permanent (and possibly a temporary) 
default list of system channels used by the roaming 
algorithm. They are stored continuously and have the 
following general format: 



channel #n 



total number of channels (2 bytes) 
system channels 



A channel is defined as a pair of frequencies and all the 
channels of this list are given in reference Rl-06. 
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6 MOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 

Rl-06, 17, 22, 31, 62 
Rl-09, 4, 7, 55, 61 
Rl-17, 5, 14, 17, 24, 50 



Below are the reference designations listed. 



Reference Section 

Rl-01 Arrangement of the documents 

Rl-02 MOBITEX System description 

R1-Q3 General description of terminals ........ 

Rl-04 Terminology 

Rl-05 References 

Rl-06 Network operator information 

Rl-0a Application layer 

Rl-09 Network layer- 

Rl-11 Interface requirements, fixed terminals 

Rl-12 Other requirements, fixed terminals 

Rl-16 Link layer, mobile terminals 

Rl-17 Physical layer, mobile terminals 

Rl-18 Radio equipment, mobile terminals 

Rl-19 Other interfaces, mobile terminals 

Rl-20 Other requirements, mobile terminals 
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MOBITEX 

Data Link Layer, Mobile Terminal 
Appendix A, Frames? 8/16 kbps 



This document describes frame structure and coding for the 
Data Link Layer. 
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l INTRODUCTION 



1.1 GENERAL 



The mobile terminal's Data Link Layer together with the 
Physical Layer form a radio protocol for communication 
between mobile stations (MOB) and a base radio station 
(BASE). 

The interchange of information between BASE and MOB is in 
the form of frames. There are 21 different types of 
frames. 
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2 FRAME TYPES 

There are 21 different frame types: 
Name 



20 
21 



M frame <MRM> 

Acknowledgement <ACK> 

Negative acknowledgement <NAK> 

Repetition request <REB> 

Repetition reply <RES> 

Access request, data <ABD> 

Access request, speech <ABT> 

Access request, emergency <ABL> 

Access permission, data <ATD> 

Access permission,, speech <ATT> 

Access permission, emergency <ATL> 

Change channel, data <BKD> 

Change channel, speech <BKT> 

Free signal <FRI> 

Sweep signal <SVF> 

Silence order . <TST> 

Activity request <AKT> 

No access permission, speech <NAT> 

Change base station, speech <BBT> 

Wait for channel , speech <VKT> 

Cancel access request, speech <AAT> 



Yes 
Yes 
Yes 
Yes 
Yes 



Yes 
Yes 
Yes 
Yes 
Yes 
Yes 
Yes 
Yes 
Yes 
Yes 
Yes 
Yes 



Yes 
Yes 
Yes 
Yes 
Yes 
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3 DESCRIPTION OF GENERAL FIELDS 

In this chapter the general fields of a frame are 
described. Fields occuring only in specific frame types 
are described in conjunction with the definition of the 
respective frame type. 

The fields are described in the following order: 

address of mobile terminal, or group 
type of frame 

number of blocks in the frame 
check sum 

for masked addressing 
for priority addressing 
frequency number, up frequency 
frequency number, down frequency 
number of retransmissions 



1 


MOB 


2 


TXPE 


3 


BLOCK 


4 


PARITY 


5 


MASK 


6 


PRIO 


7a 


UPFREQ 


7b 


DOFREQ 


8 


NUMRET 



The most significant bit lies .to the left in the field, 
has the lowest order number and is sent and received first 
in time. 



01 02 03 04 05 



21 22 23 24 



MOB states the address of the mobile unit concerned. 
This address refers to the terminals own 
subscription number, or to any number representing a 
group to which the terminal belongs. 
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TYPE is bit 28-32 of the primary block and indicates 
the type of frame according to the following table: 



Value Type 
Decimal Binary designation 



01 


00001 


<MRM> 


02 


00010 


<ACK> 


03 


00011 


<NAK> 


04 


00100 


<REB> 


05 


00101 


<RES> 


06 


00110 


<ABD> 


07 


• 00111 


<ABT> 


08 


01000 


<ABL> 


09 


01001 


<ATD> 


-10 - 


0101-0- - 


<ATT> 


11 


01011 


<ATL> 


12 ' 


. 01100 


<BKD> 


13 


01101 


<BKT> 


14 


OHIO 


<PRI> 


15 


oiiii 


<SVP> 


16 


10000 


<TST> 


17 


10001 


<AKT> 


18 


10010 


<NAT> 


19 


10011 


<BBT> 


20 


10100 


<VKT> 


21 


10101 


<AAT> 



BLOCK 01 02 03 04 05 06 07 08 
_J 1 I I I 1 1 



States the number of blocks in the frame, including 
primary block. 



PARITY 01 02 03 



A frame comprises one or more blocks. A block 
•comprises a source word and a coded parity word. 
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MASK 01 02 03 04 05 



A group of terminals is addressed with masked 
addressing. The MASK states the number of most 
significant bits of the MOB address that should be 
ignored. 



PRIO 01 02 03 



PRIO 



Meaning 



Priority group 4, 



111 
110 

5 101 Priority group 3, 

4 100 « , 

3 .011 Priority group 2, 

2 010 « , 

1 001 Priority group 1, 

0 000 " , 



raised priority 
normal 

raised priority 
normal 

raised priority 
normal 

raised priority 
normal 



DPFREQ 01 02 03 04 12 13 14 15 16 

' I 1 - ' ' ' ' ' 



I <-FBI--> I <- 
DOFREQ 01 02 03 . 



• FREQ. NO. . >l 

. 12 13 14 15 16 



States the frequency number, OPFREQ for transmit 
frequency and DOFREQ for receive frequency. 





Bit 1 to 3 gives FBI (frequency band and bit rate 
INFORMATION) and bit 4 to 16 gives the frequency 
number. Both the parameters are defined in reference 
Rl-06. 




NUMRET 


01 02 03 04 05 06 07 08 
1 1 1 1 1 I 1 








NUMRET 






States the number of retransmissions, including the 
current try. 
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4 FRAME TYPE DESCRIPTIONS 



4.1 FRAME TYPE <MRM>, M-frame 



APPLICATION 



An <MRM> is used to transfer packets. The 
packet format is defined in reference 
Rl-09. 



PRIMARY BLOCK 

01 02 03 



0 0 0 0 1 



33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 

1 1 1— j 1 1 1 I I 1 I I I I L_ 

OCTET SEQUENCE BLOCK 



49 50 51 52 53 54 . 



States the number of valid octets in the 
last following block. Remaining octets of 
the last block are filled with "0" to give 
a complete block. The field contains 6 
bits and is used in the following way: 

26 27 33 34 35 36 



States the sequential number of the frame. 

States whether a response is to be given 
to the frame. The mobile terminal shall 
always set this flag to "1" on 
transmission. 

Contains 12 octets of source data from the 
packet . 
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FOLLOWING BLOCK 
APPLICATION 



The packet is placed in the following 
blocks with 18 octets from the packet in 
each. The number of valid octets in the 
last following block is indicated in the 
OCTET field of the primary block. The last 
following block is filled with "0" in the 
octets which do not belong to the packet. 



01 02 03 04 05 06 



144 




Contains 18 octets of source data from the 
packet . 
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4.2 FRAME TYPE <ACK>, Acknowledgement 


APPLICATION An <ACK> 


acknowledges a correctly received 


frame. 





<ACK> indicates that all blocks In the 
frame have been correctly received. It 
includes the sequential number of the 
received frame. 



PRIMARY BLOCK 



01 02 


03 




22 23 24 


25 26 

1 1 


27 


28 29 


30 


31 32 


MOB 


0 0 


0 


0 0 


0 


1 0 


33 34 


35 
1 1 


36 


37 38 39 40 


41 42 


43 


44 45 


46 


47 48 


0 0 


0 


0 


SEQUENCE 


BLOCK 


49 SO 


51 


52 


53 54 




1 


_J 




. 144 


0 0 


0 


0 


0 0 




0 


0 0 


0 


0 0 


145 







1 _l 1 






1 — 1 — 




160 



PARITY 



States the sequential number of 
the corresponding <MRM>-f rame. 



No following blocks in this type 
of frame. 



FOLLOWING BLOCK 
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4.3 FRAME TYPE <NAK>, Negative acknowledgement 

APPLICATION A <NAK> requests repetition of the entire 
<HRM>. 

<NAK> indicates that the primary block has 
been correctly received, but that the 
following blocks have been lost. It 
contains the sequential number of the 
received primary block. <NAK> results in a 
complete repetition of the lost <MRM>. 

Note that if the number of blocks in <MRM> 
was 3 or more, <REB> is used instead of 
<NAK>. 



PRIMARY BLOCK- 
01 02 03 



22 23 24 25 26 27 28 29 30 31 32 



HOB 


0 0 


•0 


0 0 


0 


1 1 


33 34 

i 


35 


36 


37 38 39 40 

I II, 


41 42 

i • 


43 


44 45 


46 


47 48 


0 0 


0 


0 


SEQUENCE 


BLOCK 


49 50 

1 


51 


52 


53 54 










144 


0 0 


0 


0 


0 0 




0 


0 0 


0 


0 0 


145 








i 








160 



States the sequential number of 
the corresponding <MRM>-frame. 



FOLLOWING BLOCK 



No following blocks in this type 
of frame. 
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4.4 FRAME TYPE <REB>, Repetition request 



A <REB> requests repetition of erronous 
blacks in an <MRH>. 

If it is found during reception that 
certain blocks in a frame cannot be 
corrected^ a request for these blocks to 
be repeated can be made by transmitting a 
<REB>. The request contains a bit map of 
the blocks to be repeated. This bit map 
refers to the original <MRM>, even during 
a sequence of repetitions. 

<REB> contains the sequential number of 
the received <MRM> primary block and 
results in a <RES>. 

Note that if the number of blocks in <MRM> 
was 2 or less, <NAK> is used instead of . 
<REB>-. - 



PRIMARY BLOCK 



0 0 1 0.0 



33 34 35 36 37 38 39.40 41 42 43 44 45 46 47 



0 0 0 0 
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States the sequential number of 
the corresponding <MRM>-f rame. 

Contains a bit map where each 
bit represents a block in the 
<MRM> previously received. A bit 
set to "1" indicates chat the 
corresponding block is to be 
repeated. The bit in a HEPMAP 
representing the primary block 
shall always have the value "0", 
since repetition of the primary 
block is illegal. 



FOLLOWING BLOCK No following blocks in this type 

of frame. 
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4.5 FRAME TYPE <RES>, Repetition reply 

APPLICATION A <RES> is the reply to a <REB>. 

<RES> is a selective repetition of blocks 
from an <MRM>. The following blocks of the 
<RES> contain copies of blocks according 
to the bit map of the <REB>. <RES> 
contains the sequential number of the 
original <MRM>. 



PRIMARY BLOCK 



22 23 24 25 26 27 28 29 30 31 32 



1 1 1... _I — I — 1 — 1 

MOB 


0 0 


0 


0 0 


1 


I 

0 1 


33 34 


35 


36 


37 38 39 40 


41 42 


43 


44 45 


46 

1 ••- 1 


47 48 


0 0 


0 


0 


SEQUENCE 


BLOCK 


49 50 
..L 1 


51 


52 


53 54 

i i 










144 


0 0 


0 


0 


0 0 




0 


0 0 


0 


0 0 


145 






! I I 










160 


PARITY 



SEQUENCE States the sequential number of the 
corresponding <MRM>-frame. 
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FOLLOWING BLOCK 
APPLICATION 



The following blocks contain copies of 
blocks according to the bit map of the 
<REB>. Only blocks requested to be 
repeated shall be packed into the 
following blocks. The order of the blocks 
is that stated in REPMAP. 



01 02 03 04 05 06 



144 
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4.6 FRAME TYPE <ABD>, Access request, data. 

APPLICATION An <ABD> is a request to transmit an <MRM> 
whose length (number of blocks) exceeds 
the value of MAX_ACCESS. 

If the length of the <HRM> exceeds 
MAX_ACCESS, access must be requested 
before the <MRM> may be sent. 

The <ABD> states the number of blocks in 
the corresponding <MRM>. 



PRIMARY BLOCK 

01 02 03^ 22 23 24 25 26 27 28 29 30 31 32 

MOB 



0 0 0 



0 0 



1 0 



33 34.35 36 37 38 39 40 41 42 43 44 45 46 47 48 
■ 1 1 1 1 l ■ ........ 



49 50 51 52 53 54 55 56 57 
1 1 1 1 I I ' 



NOMRET 



States the number of blocks for 
.which access is requested. 



FOLLOWING BLOCK 



No following blocks in this type 
of frame. 
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4.7 FRAME TYPE <ABT>, Access request, speech 

APPLICATION An <ABT> is a request to transmit an <MHM> 
containing a request for a line 
connection, whose length (number of 
blocks) exceeds the value o£ MAX_SPEECH. 

The <ABT> states the number of blocks in 
the corresponding <MRM>. 



PRIMARY BLOCK 



22 23 24 25 26 27 28 29 30 31 32 



0 0 111 



33 34 35 36 37 38 39 40 41 42 ^ 43 ^ 44 ^ 45 < 46 < 47 



49 50 51 52 53 54 55 56 57 



States the number of blocks for 
which access is requested. 



FOLLOWING BLOCK 



No following blocks in this type 
of frame. 
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4.8 ERAME TYPE <ABL>, Access tequest, emergency. 

APPLICATION An <ABIi> is a request to transmit an <MRM> 
containing an emergency signal whose 
length exceeds the value of MAX_ACCESS. 

If the length of the <MRM> exceeds 
MAX ACCESS i access must be requested 
before the <MRM> may be sent. 

The <ABL> states the number of blocks in 
the corresponding <MRM>. 



PRIMARY BLOCK 

01 02 03 22 23 24 25 26 27 28 29 30 31 32 

MOB 



0 0 0 



0 10 0 0 



33 34 35 36 37 38 39 40 41 42 .4.3 44 45 46 47 48 



49 50 51 52 53 54 55 56 57 



States the number of blocks for 
which access is requested. 



FOLLOWING BLOCK 



Mo following blocks in this type 
of frame. 
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4.9 FRAME TYPE <ATD>, Access permission, data. 




APPLICATION BASE replies with an <ATD> to an <ABD> 

frpm a MOB, when BASE is ready to accept 
an <MRM>. 




When permission is granted, MOB is. 
expected to transmit an <MRM> containing a 
data packet. 


PRIMARY BLOCK 












01 02 03 22 


23 24 


25 26 27 


28 29 30 31 32 
,!._ J 1 1 






MOB 


0 0 0 


0 10 0 1 






33 34 35 36 37 38 

1 t 1 1 L 


39 40 


41 42 43 


44 45 46 47 48 






0 0 0 0 0 0 


0 t) 


BLOCK 






49 50 51 52 53 54 
1 1 .1 . ,1 1 L 




1 — 


144 

! 1 1 1 






0 0 0 0 0 0 




0 


0 0 0 0 0 






145 






160 






PARITY 





No following blocks in this type 
of frame. 
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4.10 FRAME TYPE <ATT>, Access permission, speech. 

APPLICATION BASE replies with an <ATT> to an <ABT> 

from a HOB, when BASE is ready to accept 
an <HRM>. 

When permission is granted, MOB is 
expected to transmit an <MRM> containing a 
request for line connection. 

PRIMARY BLOCK 

01 02 03 22 23 24 25 26 27 28 29 30 31 32 
I I I I i i I i I I I I i i__ 

MOB 00001010 



0 0 0 0 0 0 0 0 



49 50 51 52 53 54 



0 0 0 0 0 0 



0 0 0 0 0 0 



— I 1 1 1 1 1_ 



FOLLOWING BLOCK 



No following blocks in this type 
of frame. 
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4.11 FRAME TYPE <ATL>, Access permission, emergency. 

APPLICATION BASE replies with an <ATL> to an <ABL> 

from a MOB, when BASE is ready to accept 
an <MRM>. 

When permission is granted, MOB is 
expected to transmit an <MRM> containing 
an emergency signal. 



PRIMARY BLOCK 

01 02 03 



22 23 24 25 26 27 28 29 30 31 32 



0 10 1 1 



33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 



00000000 



49 50 51 52 53 54 



0 0 0 0 0 0 



0 0 0 0 0 



FOLLOWING BLOCK 



No following blocks in this type 
of frame. 



Exhibit 2, 



P- 



Cantel Mobitex- 



91/1056 - A 296 5171/A2 De 



1990-02-22 A 



4.12 FRAME TXPE <BKD> , Change channel, data- 
APPLICATION 



A <BKD> orders a MOB to another channel in 
order to transmit or receive an <MRM>. 

The MOB usually returns to the original 
channel when the <MRM> has been 
transmitted or received. If an error 
occurs on the assigned channel then MOB 
returns to the original channel after a 
timeout period stated in the <BKD>. 



PRIMARY BLOCK 

01 02 03 



0 110 0 



33. 34 35 36 37 38 39 40 41 42 43 44 45 46 47 ■ 



OO OOOOOO 



97 



64 65 80 81 

OPFREQ 



TIMEOUT 



dofre q" ' | 



0 0 0 0 0 
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Indicates how the terminal is to act on 
the new channel. 

. 1 . Reserved 

2 Reserved 

3 Reserved 

4 Change to send <MRM> 

5 Change to receive <MRM> 
6.. 16 Reserved 



Frequency number for up frequency, i.e. 
the frequency on which the terminal 
transmits. 

Frequency number of down frequency, i.e. 
the frequency on which BASE transmits. 

If error, return after TIMEOUT seconds 
(1-255). 



FOLLOWING .BLOCK 



No following blocks in this type 
of frame. 
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4.13 FRAME TYPE <BKT> , Change channel, speech. 

APPLICATION A <BKT> orders a MOB to another channel in 
order to transmit or receive an <MRM> 
containing a request for line connection. 

Normally the terminal returns to the 
original channel when the line connection 
is over. If an error occurs on the 
assigned channel then. MOB returns to the 
original channel after a timeout period 
stated in the <BKT>. • 



PRIMARY BLOCK 



0 110 1 



33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 



| 0 0 0 0 
49 

| BKTFL 
97 

| ' T IMEOUT 



64 55 80 81 

OPFREQ 



dofreq " ' | 



0.0 0 0 0 
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SEQUENCE Only valid if BKTFL bit 6 is TRUE. 

BKTFL Indicates how the terminal is to act on 
the new channel. 

Bit 1 - Reserved 

2 Reserved 

3 Reserved 

4 Change to send <MRM> 

5 Change to receive <MRM> 

6 Acknowledgement. ( including sequence 
number) of correctly received speech 
<MRM>. Ignore timeout. 

7 . . 16 Reserved 



UPFREQ ■ Frequency number for up frequency, i.e. 
the frequency on which the terminal 
transmits. 

DOFREQ Frequency number of down frequency, i.e. 

the frequency on which BASE transmits. 

TIMEOUT If error, return after TIMEOUT seconds 
(1-255). 



FOLLOWING BLOCK 
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4.14 FRAME TYPE <FRI>, Free signal 
APPLICATION 



BASE transmits a <FRl> when it is ready to 
handle traffic from MOB. 

A free signal precedes a free cycle. A 
free cycle is a period of time when all 
of., or parts of, the total fleet of mobile 
terminals are collectively permitted to 
transmit. 



PRIMARY BLOCK 



0 1110 



33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 



49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 



RAND SLOTS 



FREE SLOTS 



65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 I 



MAX ACCESS 



SLOT LENGTH 



81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 

I 1 I I 1 1 1 1 1 1 ' 1 1 1 1 

MAX SPEECH 00000000 



0 0 0 0.0 0 



0 0 0 0 0 0 
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FFG The FFG field states the type of traffic 

to which the free signal applies according 
to the following table. 


Vaiue Emergency Soeech Data 


00 
01 
10 
11 


yes no no 
yes no yes 
yes yes no 
yes yes yes 


RAND SLOTS 


The maximum, number of the random 
number generator which selects 
in which slot. the transmission 
shall start. 


FREE_SLOTS 


The number of free slots in this 
free cycle. 


MAX_ACCESS 


States the number of blocks 
which may be sent in an <MRM> 
without being preceeded by an 
access request. 


SLOT_LENGTH . 


Current value of slot_length. 


MAX_SPEECH 


States the -number of blocks 
which- may be sent in a line 
connection request without being 
preceeded by an access request. 


FOLLOWING BLOCK 


No following blocks in this type 
of frame. 



AZI231S3I3 
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4.15 FRAME TYPE <SVP>, Sweep signal 

APPLICATION The sweep signal is a periodically 

recurring signal from BASE. An <SVP> is 
transmitted by BASE for two reasons: 

1 <SVP> marks the start of a sweep 
cycle . 

2 <SVP> contains system 
parameters. 

<SVP> has 2 different subtypes: 

1 states the values of system 

parameters 

• 2 states the frequency of 

different channel types 
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<SVP>, SUBTYPE 1 



■ states the values of system 
parameters. 



PRIMARY BLOCK 

. 01 02 03 22 23 24 25 26 27 28 29 30 31 32 



MOB 


ii i i i i 
0 0 0 0 1 1 1 1 


33 34 35 36 37 38 39 40 

ii .ill 


41 42 43 44 45 46 47 48 

i i- i i i i i 


PRIO MASK 


BLOCK 


49 50 51 52 53 54 55 56 

i t i i i i i 


57 58 59 60 61 62 63 64 
1 ,..! 1 1 1—1 ! 1 


SVPTYP 


TXPOW 


65 66 67 68 69 70 71 72 
i i i i i i i 


73 74 75 76 77 78 79 80 


RSSI PROC 


RSSI PERIOD 


81 82 83 84 85 86 87 88 

i i i i i i i. 


89 90 91 92 93 94 95 96 

i i ' i i i i 1 


TIME TO NEXT 


" .MAX REP 


97 104 

i i i t i i i . 


105 112 


BASEST 


SCAN_TIME 


113 120 
III J 1 1 ! 


121 128 


BAD BASE 


GOOD_BASE 


129 136 
l„ .1 ... J 1 1 1 1 


137 144 

i i i i i _i __ _ t — i 


BETTER BASE 


00000000 


145 160 
1 1 1 1 1 ! 1 1 1 1 1 1 1 " 1 


PARITY 
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SVPTYP 


States the <SVP> subtype, value 
00000001 in this case. 


TXPOW 


States the decrease in output 
power (0-255 dB below nominal 
level) to be used by the mobile. 
A default value of 0 is used 
until this signal is received. 


RSSI_PROC 


States, the method of the signal . 
strength measurement: 

0 = FRAME 

1 = CONTINUOUS 

The default value is FRAME. 


RSSI PERIOD 


Time used by .the roaming 
algorithm (0-255 *20 ms) . 
Default value: 148 (2 960 ms). 


TIHEJP_OjaEXT„. 


States the time in seconds to 
the next <Svl»> frame. 
Default value: 10. 


MAX REP 


States the value of the variable 
Max_rep. 


BASEST 


States status of base station. 


SCAN_TIME 


States the length of a period 
(0-255 *100 ms) when the 
terminal scans other system 
channels . 

Default value: 30 (3 seconds). 


BAD_BASE 


Used by the roaming algorithm. 
0-255 dBuV. Default value: 15. 


GOOD_BASE 


Used by the roaming algorithm. 
0-255 .dBuV. Default value: 15. 


BETTER_BASE 


Used by the roaming algorithm. 
0-255 dB. Default value: 10. 


Most of the parameters above are further described in the 
MAIN DOCUMENT. 



A49SS15M 
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FOLLOWING BLOCKS 



FOLLOWING BLOCK #1 



If any, they contain a list of 
system channels to be used in 
base station monitoring. A frame 
with a list containing new 
system channels completely 
overrides the previous frame. 
The channel list has the 
following format (as described 
in the MAIN DOCUMENT) : 



01 02 03 04 05 

i i i i 


05 07 08 

i i 


09 10 11 12 13 

i i i- i 


14 15 16 


number of channels 


0 0 0 0 0 


0 0 0 


17 


32 


33 48 


channel #1 - 


UPFREQ 


channel #1 - 


DOFREQ 


49 


64 

, -J 1 


65 


80 


. channel #2 - 


UPFREQ 


channel #2 - 


DOFREQ 


81 


96 

1.. , 1 


97 


.112 


channel #3 - 


UPFREQ 


channel S3 - 


DOFREQ 


113 


128 
. 1 I 


129 


144 


channel #4 - 


UPFREQ 


channel #4 — 


DOFREQ 



PARITY 



The number of following blocks depends on the size of the 
list. The maximum number of channels in the list is stated 
in reference Rl-06. 

Continues with following block #2 on the next page. 
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FOLLOWING BLOCK #2 



DPFREQ 


channel #5 - 


DOFREQ 


48 

I , .1 


49 


64 

1 1 


DPFREQ 


channel #6 - 


DOFREQ 


144 

1 1 


145 


160 


UPFREQ 


PARITY . 



channel #9 - DOFREQ 


channel #10 - UPFREQ 


33 48 
1 1 _l 1 1 


49 64 


channel #10 - DOFREQ 


channel #11 - DPFREQ 
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<SVP>, SUBTYPE 2 



• states the frequency of 
. different channel types. 



PRIMARY BLOCK 

01 02 [ 03 [ 22 23 24 25 26 27 28 29 30 31 32 

HOB 



0 0 0 



0 1111 



33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 ' 



| ...L....J | 

PRIO 


MASK 


BLOCK 


49 50 51 


52 


53 54 55 56 


57 


58 59 60 61 


62 


63 


64 


SVPTYP 


CHATYP 


65-66 67 


68 


69 70 71 72 


73 


74 75 76 77 


78 


79 


80 


OPFREQ 


81 82 83 
i i 


84 


85 86 87 88 

i i i 


89 


90 91 92 93 

i i i 


94 


95 


96 


DOFREQ 


97 98 99 


100 








144 


0 0 0 


0 


0 0 




0 0 0 


0 


0 


0 
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States the type of channel: 
Value: 

1 Local system channel opened 

2 Not used (ignore that order) 

3 Local system channel closed 
(return to national system 
channel ) 

4 Access channel opened 

5 Access channel closed 

Frequency number for up frequency, i.e. 
the frequency on which the terminal 
transmits. 

Frequency number for down frequency, i.i 
the frequency on which BASE transmits. 



FOLLOWING. BLOCK 
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4.16 FRAME TYPE <TST>, Silence order 
APPLICATION 



Silence order is used by BASE to withdraw 
all access permissions during a free 
cycle- A MOB that is already transmitting 
may continue to do so, but for every other 
MOB the access permissions for all traffic 
types { emergency! speech and data) are 
withdrawn. 

Note: Please also refer to the description 
of the silence signal in reference 
Rl-17. This signal has the same 
meaning as the <TST>-frame but uses 
only the frame head and thus 
addresses ALL mobile terminals. 



PRIMARY BLOCK 

01 02 03 



1 0 0 0 0 



33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 - 



0 0 0 0 0 0 



FOLLOWING BLOCK No following blocks in this type 

of frame. 
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4.17 FRAME TYPE <AKT>, Activity request 

APPLICATION An <AKT> is used by BASE to check whether 
a oertain HOB is active. MOB replies with 
an <ACK> to such a frame. 



PRIMARY BLOCK 



22 23 24 25 26 27 28 29 30 31 32 



1 0 0 0 1 



00000000 



49 50 5152 53 54 



0 0 0 0 0 0 



0 0 0 0 0 0 



FOLLOWING BLOCK 



No following blocks in this type 
of frame. 
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4.18 FRAME TYPE <NAT>, No access permission, speech 

APPLICATION BASE replies with <NAT> to an <ABT> or a 
line connection request from a MOB when, 
for some reason, a line connection cannot 
be set up (e.g. no channel is available). 



PRIMARY BLOCK 

01 02 03 



22 23 24 25 26 27 28 29 30 31 32 



000000 00 



Contains the following orders: 
Leave CURRENT_BASE. 
Reserved 



FOLLOWING BLOCK 



No following blocks in this type 
of frame. 
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4.19 FRAME TYPE <BBT>, Change base station/ speech. 

APPLICATION BASE will use <BBT> 

- as a response to an <ABT> when another 
base station is to be used for the line 
connection 

or 

- to hand over a call in progress to 
another base station. 



PRIMARY BLOCK 

01 02 03 



22 23 24 25 26 27 28 29 30 31 32 



III II .. .(. 

MOB 


0 0 0 


1 


0 


0 


1 

1 1 


33 34 


35 


36 37 38 39 40 


41 42 43 


44 


45 


46 


47 48 


TIMEOUT.. 


BLOCK 


49 50 


51 


52 53 54 55 56 


57 58 59 

i i 


60 


61 


62 


63 64 


BBTFL 


65 66 


67 


68 69 70 71 72 


73 74-75 


76 


77 


78 


79 80 


SPEECH DPFREQ 


81 82 


83 


84 85 86 87 88 


89 90 91 

i i 


92 


93 


94 


95 96 
L 1 1 


SPEECH DOFREQ 


97 98 


99 


100 










112 


BASE 


113 






i i 


1 


,. 




128 

1... 


NEW SYSTEM UPFREQ 


129 




i i i i 






1., ._ 




144 


NEW SYSTEM DOFREQ 


145 




i. i i i 


i i i 






1 


160 
J 1 1 


PARITY 
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TIMEOUT If error, return after TIMEOOT seconds 
(1-255). 

BBTFL Indicates the terminal is to act after 
changing to the new base station. 

Bit 49 Reserved 

50 Reserved 

51 After the call, use BASE as new current 
base station. 

52 After the call, return to old current 
base . 

53 Change and start the call set_up procedure 
from the beginning (new <ABT> on BASE). 

54 Change and continue (either signalling 
procedure or call in progress), 

55-64 Reserved 

BASE The identity of the new base station to be 

used. 



SPEECH UPFREQ 
SPEECH DOFREQ 
NEW SYSTEM DPFHEQ 

NEW SYSTEM DOFREQ 



Frequency number for 
transmitting speech. 

Frequency number for receiving 
speech. 

Frequency number for upwards 
traffic on 'the new system 
channel, i.e. the frequency on 
which the terminal transmits. 

Frequency number for downwards 
traffic an the new system 
channel, i.e. the frequency on 
which the terminal receives. 



FOLLOWING BLOCK 



No following blocks : 
of frame. 



This order is only valid if both BBTFL 3 and BBTFL 6 are 
raised, i.e. hand over of a call in progress. 

Other combinations of BBTFL are to be included in later 
versions. 



Exhibits p. 651 



Cantel Mobitex- 



91/1056 - A 296 5171/A2 Ue 



1990-02-22 A 



4.20 FRAME TYPE <VKT>, Wait for channel, speech 

APPLICATION BASE replies with one (or more) <VKT>- 
frame(s) to an <ABT> from a MOB when a 
speech channel is not immediately 
available. 



PRIMARY BLOCK 

01 02 03 



22 23 24 25 26 27 28 29 30 31 32 



III.. ..l.-.-J — 1 — 

MOB 


., 1 „ 
0 0 


0 


1 0 


1 


0 0 


33 34 

1 


35 36 37 


38 


39 40 


41 42 


43 


44 45 
i 


46 


47 48 


0 0 


0 0 0 


0 


0 0 


BLOCK 


49 50 


51 52 53 


54 


55 56 


57 58 

i 


59 


60 61 
i 


62 


63 64 


TIMEOUT 


QPOS 


65 66 
i 


67 68 69 
1 — 1. ...J 1 


70 








1 




144 


0 0 


0 0 0 


0 






• 0 


0 0 


0 


0 0 


145 

L -J _J 












1 _J 




160 

1 



TIMEOUT If the mobile terminal has not received a 
<BKT> or a <NAT> within TIMEOUT seconds 
(0-255), the <VKT> is invalidated. 

QPOS States current position (1-255) in queue. 

It is recommended that this parameter is 
passed on to the application layer and 
shown to the operator. 



FOLLOWING BLOCK 



No following blocks in this type 
of frame. 
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4.21 FRAME TYPE <AAT>, Cancel access request, speech 



APPLICATION 



HOB transmits an <AAT> when it wants to 
end a call and has been placed in a queue 



PRIMARY BLOCK 

01 02 03 



10 10 1 



33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 



00 0 00000 



49 50 51 52 53 54^55 56 -57- 



0 0 0 0 0 0 0 



FOLLOWING BLOCK 



No following blocks in this type 
of frame. 
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5 CONVERTING A PACKET TO A FRAME 



<MRM>-f raraes conveys MPAKs over the radio channel. The 
primary block can accomodate 12 and each following block 
18 octets from the MPAK. 



Frame head 
HOB address 



Control field 



Parity field 



Primary block 
with link layer' 
information 



Following 
block #1 • 



Parity field 



When converting a packet to a frame, the first 12 octets 
in the' packet shall be .placed in the primary block of the 
frame. The last octets of the packet are placed in the 
last block. The primary block indicates how many octets in 
the last following block that are used. Unused octets in 
the last following block are filled with octets containing, 
zeros. 

In the primary block of the <MRM>-frame the Link Layer 
information is added. The MOB address field of the primary 
block shall always contain the MAN of the physical 
terminal concerned or, when the base station is 
transmitting to a group, the MAN of the addressed group. 
The base station identity is contained in the frame head 
preceding the primary block. 

The addresses in the MPAK itself indicates the sub- 
scriptions concerned (terminal, transferable or group). 
For packets to/from the' terminal itself or its group 
numbers, the MOB address field of the primary block and 
the address in the MPAK are the same. For packets to/from 
a transferred subscription, the corresponding addresses 
differ. 
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6.1 GENERAL DESCRIPTION 

The code used is a cyclic block code for burst error 
control. The code message consists of 144 source data bits 
and a block check character (CRC, i.e. parity) of 16 bits, 
giving a total of 160 bits in a block. 

The generator polynomial defining the code is 

g(X) = X 1S + X 12 + X 5 +1 

i.e. CRC-CCITT X.25. 

The CRC is initialized to all ones, calculated from all 
the 144 source" data bits of the block and then its one's 
complement is transmitted. 

This code detects all (single) error bursts up to 16 bits 
in length and about 99,998% of all other error patterns. 



6 . 2 IMPLEMENTATION 

CRC calculations are customarily done in a multi-section 
shift register which feeds into an exclusive-OR gate whose 
output feeds back to other XOR gates located in between 
the sections of the shift register. The placement and 
quantity of XOR gates are defined by the generator 
polynomial. 

The CRC is then transmitted after the source data of the 
block . 

A logical arrangement identical to that used in the 
transmitter is also used in the receiver. Again the CRC- 
register is initialized to all ones, the CRC is calculated 
from the 144 source bits and its one's complement is 
compared to the received CRC. If thes are different an 
error has been detected. 

Instead of hardware logic a software algorithm may be 
used. 
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7 MOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 

Rl-06, 7, 31 
Rl-09, 8 
Rl-17, 35 



Below are the reference designations listed. 



Reference Section 

Rl-01 Arrangement of the documents 

Rl-02 MOBITEX System description 
--^Rl-03 General description of terminals 

Rl-04 Terminology 

Rl-05. References 

Rl-06 Network operator information 

Rl-08 Application layer 

Rl-09 Network layer 

Rl-11 Interface requirements, fixed terminals 

Rl-12 Other requirements, fixed terminals 

Rl-16 Link layer, mobile terminals 

Rl-17 Physical layer, mobile terminals 

Rl-18 Radio equipment, mobile terminals 

Rl-19 Other interfaces, mobile terminals 

Rl-20 Other requirements, mobile terminals 
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ABSTRACT 

This document specifies the Physical Layer for mobile 
terminals connected to the MOBITEX network. 

The exchange of information between base radio station and 
mobile is done'by frames. A frame consists 'of a frame head 
and blocks. 

The frame head is added to the message sent by the Data 
Link Layer to establish synchronisation and identify the 
base station. It also includes a set of control flags. 

The blocks in a frame contain the data to/from the Data 
Link Layer plus parity bits" for error correction. 
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INTRODOCTION 



The protocol in the Physical Layer describes the way the 
mobile terminal handles the radio channel. The logical 
structure of the protocol is described in this document, 
while hardware-related functions such as: 

method of modulation 

suitable equipment for implementation 

requirements for the equipment 



are presented in reference Rl-18. 
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2.1 GENERAL CHARACTERISTICS 

The channel between the base radio station and the mobile 
terminal uses 

separate frequencies for transmission and reception, 
synchronous communication and 
frequency modulation (FM). 
It. is also affected by 

varying .field-strength, 

random errors and burst errors caused by fading and 
noise and - - . . - 

bit errors caused by ignition interference. 

Consideration has been given to these and other factors in 
the design of the protocol for the Physical Layer. 



2 . 2 FRAME STRUCTURE 

The exchange of information between base station and 
mobile is done by frames. A frame has the following 
structure: 



[Frame head| Block #1 Block #2 j | Block ffn 



The frame head is a very important part of the frame. It 
is added to the message sent by the Data Link Layer to 
establish synchronisation and identify the base radio 
station. 

The blocks in a frame contain the data to/from the Data 
Link Layer plus parity bits for error correction. 

When the number of blocks is zero, i.e. when only a frame 
head is sent, the term "signal" is used. 
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3 THE FRAME HEAD 



3 . 1 STRUCTURE 



The frame head has the following structure: 
01 02 03 04 05 06 07 08 09 .10 11 12 13 14 15 16 



BIT SYNCHRONISATION 


17 


18 


19 20 21 22 


23 24 25 26 27 28 

i i i i i 


29 30 


31 32 


FRAME SYNCHRONISATION. 


33 


34 


35 36 37 38 

i i i 


39 40.4.1 42 43 44 


45 46 


47 48 


BASE IDENTITY 


AREA IDENTITY • 


CTRL 


FLAGS 


49 


50 


51 52 53 54 
i i i 


55 56 







PARITY BITS 



The different parts of the frame head are described in the 
following chapters. 
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3.2 SYNCHRONISATION 



3.2.1 Bit synchronisation 

This preamble is provided to enable bit sychronisation in 
the demodulator. It consists of 16 bits with the following 
pattern (bit #1 is. sent first): 

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 



110 0 11 
0 0 110 0 



01100 110 
1 0 0 1 1 0 0 1 



from BASE 
from MOB 



3.2.2 Frame- synchronisation 

The frame synchronisation is provided to establish correct 
code word f raming. Each . network, has its own pattern, used 
as network identification number, defined in reference Rl- 
06. In order to roam into base radio stations in other 
networks, it should be possible to manually change the 
frame synchronisation word from the application layer. 

It consists of 16 bits with the following structure, with 
bit #1 sent first: 



01 02 03 04 05 06 07 I 



I 09 10 11 12 13 14 15 16 



xxxxxxxxxxx 
xxxxxxxxxxx 



: from BASE 
: from MOB 



If there is more than 1 bit error in the detected pattern, 
then frame sync is not established. 

NOTE Only these 16 bits are used for frame 
synchronisation. 
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3.3 AREA IDENTITY, BASE IDENTITY AND CONTROL FLAGS 



The base identity (6 bits) and the area identity (6 bits) 
together, states the unique identity of the base radio 
station concerned. The most significant bit (01) in the 
addresses is sent first. 

The base identity is followed by four control flags. They 
are only used in traffic from BASE to MOB. The control 
flags are as follows (in order of reception): 



1 SA_flag Reserved for future use. 

2 Set_slot flag 0 = FALSE 

~ 1 = TRUE, reset slot clock. 



3 Roaming flag- 0 = FALSE 

~ 1 = TRUE, this is a roaming signal, i.e. 

it contains only a frame head. 



4 Silence_flag 0 = FALSE 

1 = TRUE, this is a ..silence signal, i.e. 
it contains only a frame head.. 



01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 

I I I I I 1 1 l—J 1 !— 1 1 1 1 

BASE IDENTITY AREA IDENTITY CTRL FLAGS 



17 18 19 20 21 22 23 24 



The 8 (2*4) parity bits that follow the control flags are 
encoded in the same way as the blocks of the frame. Parity 
#1 is coded from octet #1 (see figure above) and parity #2 
from octet #2. 



The code corrects all single errors. In case- the frame 
head could not be corrected, it should be rejected. 



The parity bits may be ignored and the base identity and 
control flags read without any decoding. 



A.292 3U3I3 
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4 ERROR CORRECTION AND DETECTION 



Each block to/from the Data Link Layer contains 20 octets 
of information. These are put into a matrix of the 
following format: 



column — 1 2 3 4 5 6 7 8 9 10 11 12 . 



octet #1 


parity 


octet #2 





To each octet (column 1-8) four parity bits are added in 
the same row (9-12). These are encoded by a shortened 
(12,8) Hamming code. 



The code corrects all single errors with hard decision 
decoding . 



The code is defined by the following H-matrix: 
' 11101100 1000 " 
11010011 0100 
H = 10111010 0010 
. 01110101 0001 . 

The syndrome (s) is calculated from the received code word 
(v) by 



where H T denotes the transposed H-matrix. 
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The syndrome of a code word with a single error is equal 
to the columnvector of the H-matrix corresponding to the 
position of this error. The syndrome table is shown below. 



syndrome 


corresponds to 
a single error 
in bit position 


0 
1 


0000 0000 0001 


2 


0000 0000 0010 


3 




4 


0000 0000 0100 


5 


0000 0001 0000 


6 


0000 0010 0000 


7 


0001 0000 0000 


8 


oooo- 0000 1000 


9 


0000 0100 0000 


10 


0000 1000 0000 


•-11 - 


0010 0000 0000 


12 




13 


0100 0000 0000 


14 


1000 0000 0000 


15 





If the syndrome is 0 the code word is correct. 



The following examples illustrate the coding/decoding 
procedure: 



transmitted 
info parity 



0000 0001 0101 



0000 0101 1100 



received 

info parity 



0000 0001 0101 



0101 0101 1100 



syndrome 
0000 

1010' 



0000 0010 0110 0010 0010 OllOl 1011 



[oooo 0101 1 1100 1 [oooo 1111[1100| 1100 
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4.2 INTERLEAVING AND SCRAMBLING 

Before transmission the code is interleaved to give 
protection against burst errors. The block-matrix is sent 
columnwise with start at position (1,1) and is received in 
the same way. 

column — 1 2 3 4 5 6 7 8 9 10 11 12 



row 1 


octet 


#1 


parity 


2 


octet 


#2 










20 


octet 


#20 





The., code .without interleaving can correct single errors. 
The interleaved code can thus correct a burst of 20 
errors, assuming that there is no other error in the same 
block. 



Scrambling 

At transmission and reception the bits following the frame 
head should be added modulo-2 (exclusive-ored) with the 
output from the ninth stage of a binary nine-stage shift 
register. 

The outputs of the fifth and ninth stage of the shift 
register should be added modulo-2 and the result fed back 
to the input of the first stage. 

All bits in the shift register should be sent to the 
logical value 1 upon initialization for reception or 
transmission. 

That is, the bits following the frame head will be - 
exclusive-ored with the sequence: 

111111111000001111011111000101 , etc. 

This scrambling sequence is the recomended test sequence 
described in CCITT recommendation V.52, as well as the 
shift register on the next page. 



Note: It should be possible, via a test command in MASC 
(reference Rl-19 ), to order the mobile to • 
start/stop sending the above described scrambling 
sequence. This should only be possible during test, 
not during normal operation. 
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Shift register stages during pseudo-random pattern 
generation. 



1 

1 


2 


3 


4 


1 

5 


6 


7 


a 


9 


Out 


1 


1 


1 


1 


1 


1 


1 


l 


i 


1 


0 


1 


1 


1 


1 


1 


1 


l 


i 


1 


0 


0 


' 1 


1 


1 


1 


1 


l 


l 


1 


0 


0 


0 


1 


1 


1 


1 


l 


i 


1 


0 


0 


0 


0 


1 


1 


1 


l 


' l 


1 


0 


0 


0 


0 


0 


1 


1 


i 


i 


1 


1 


0 


0 


0 


0 


0 


1-- 


l 


l 


1 


1 


1 


0 


0 


0 


0 


0 


l 


l 


1 


1 


1 


1 


0 


0 


0 


0 


0 


l 


1 


1 


1 


1 


1 


0 
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0 


0 
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1 


1 
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1 
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1 
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1 


1 


1 


1 


0 


0 


0 


1 


1 


1 


0 


1 


1 


1 


1 


0 


0 
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1 


1 


0 


1 


1 


1 


1 


1 
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5 TIME DIVISIOH 



The time axis is divided into slots. The length (L) of one 
of these slots. is given by the parameter Slot_length. 



I slot n [slot n+1 jslot n+2 jslot n+3 | _ 

.+ + _ — + h + > t ime 

t t+L t+2L t+3L t+41, 



The mobile keeps a clock going to be able to detect slot 
boundaries. The start (tl) of the first slot in a sequence 
is defined by BASE transmitting a frame head with a 
Set_slot_flag»- 



) frame head) block $1 \ 

tO tl = t0 + 20 i 



The first bit of the frame head is received at time to. 
Slot number n starts at: 

t.» tl + (n-l)*L 

where 

L = .Slot_length * (32/bitrate) seconds 
n = 1. .x 



The tolerance for determining the start of a slot is 
-0.1/+3 ms. 
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6 TRANSMISSION 



When an order to transmit a frame (FRAME_TO_SEND) has come 
from the Data Link 'Layer, the Physical Layer first waits 
until the slot clock reaches the CHOSEN_SLOT (please also 
refer to chapter 8) before it: 

indicates SLOT_REACHED to the Data Link Layer 
switches the carrier on 

waits until carrier frequency and power has 
stabilized 

waits 5 ras (tolerance -0/+5 ms) 

sends frame head with base and area identity (from 
Current_base) and all control flags = 0 (i.e. FALSE) 
encodes and sends all blocks of the frame 



before it switches the carrier off and indicates 
FRAME_S£NT to the Data Link Layer. If the order 
CANNOT SEND comes from the Data Link Layer before the 
CHOSENJSLOT is reached, then the transmission will not be 
started. 
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7 RECEPTION 



The following takes place when correct bit and frai 
synchronisation has' been established: 



get average signal strength during reception of 

frame head *) 
send Received base to Data Link La yer 
IF received Ease = Current_base THEN 

IP Silence_flag THEN 

send Silence to Data Link Layer 

ELSE 

IP Set slot_flag THEN 

reset~slot clock 
ENDIF 
REPEAT 

read block 

decode block 

send Received block to Data. Link Layer . 
UNTIL Sync_search 
ENDIF 
ENDIF 



On reception of the order Measure_RSSI from the Data Link 
Layer, the average signal strength *) is measured during 
the time stated in the order. Thereafter an answer, 
RSSIjneasured, is sent to the Data Link Layer. 



*) The RSSI should be sampled with a frequency of 1000 
samples per second. 



A232S1S3.-3 
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8 INTERFACE TO THE DATA LINK LAYER 



Parameters received from the Data Link Layer: 



Slot_lertgth - states the length of a single slot. The 
unit is {32/bitrate) seconds. 

Chosen_slot - states the slot where transmission 
starts. 

Current_base - states which base radio station is 

currently used (base and area identity). 

Frame to send - is a message consisting of at least one 
block. 

Frame_length - states the number of blocks in message. 

Sync_sear.ch .-...orders, the Physical Layer to stop 
reading and enter sync search mode. 

Cannot_send - orders the Physical Layer not to send in 
any- slot. 

Measure_RSSI - orders the Physical Layer to measure the 
• average received signal strength, during 
the time stated in the order. 



Parameters sent to the Data Link Layer: 



Frame sent - indicates that a frame transmission is 

"~ completed. 

Received_block - is a decoded block (w error indication). 

Receivedjbase - states the base identity, area identity 
and the received signal strength in 
dBuV. 

Silence - indicates that we have received a 

silence signal. 

Slot_reached - indicates the start of the Chosen^slot. 

RSSI Measured - the average received signal strength, 
~ during in order Measure_RSSI stated 

time. 
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9 MOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references/ made to 
other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 

Rl-06, 6 
Rl-18, 3 
Rl-19, 10 



Below are the reference designations listed. 



Reference Section 

Rl-01 Arrangement of the documents 

Rl-02 MOBITEX System description 

Hl-03 General description of terminals 

Rl-04 Terminology 

Rl-05 References 

Rl-06 Network operator information 

Rl-08 Application layer 

Rl-09 Network layer 

Rl-11 Interface requirements, fixed terminals 

Rl-12 Other requirements, fixed terminals 

Rl-16 Link layer, mobile. terminals' 

Rl-17 Physical layer, mobile terminals 

Rl-18 Radio equipment, mobile terminals 

Rl-19 Other interfaces, mobile terminals 

Rl-20 Other requirements, mobile terminals 
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MOBITEX 

Mobile radio equipment 

8 kbit/s, 12.5 kHz channel spacing 



ABSTRACT 



This document specifies the requirements for the radio 
transmitter and receiver in the MOBITEX MOBILE TERMINAL. 

The document contains a functional description and a 
detailed specification of the technical requirements and 
performance .of the transmitter and receiver. 

The equipment specified in this document . should also meet 
with basic requirements set up in national regulations for 
radio transmitters and radio receivers. 

Environmental, power supply and operational control 
requirements are found in the document General 
Requirements for the Mobile Terminal. 
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1 INTRODUCTION 



1.1 GENERAL 

The radio transceiver serves as interface between the 
. radio path and the logic and control unit of the mobile 
. terminal. Data and voice transmission is provided. 

The transmission mode is semi-duplex, the base station 
operates in full duplex mode and the mobile station in two 
frequency simplex mode. 

Digital FM modulation is used for data transmission at a 
speed of 8 kbit/s. 

The channel spacing is 12.5 kHz. 
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2 FUNCTIONAL DESCRIPTION 



2.1 DATA TRANSMISSION 

The main traffic in the Mobitex network will be of the 
data transmission type. 

A modulation type which makes it possible to utilize the 
radio transceiver for speech transmission as well as for 
data transmission has been chosen. 

The modulation type is binary digital baseband filtered PH 
at a speed of 8 kbit/s. 

There should be no squelch function during data 
transmissions.. 

During data transmissions the audio paths for speech 
transmissions to be muted. 

The data transmission mode is used for" transmission of 
system information, system orders and for ehe signalling 
between the base station and the mobile station as well as 
for the user data and text transmissions. 

The data transmission mode is basically a simplex mode, 
data transmission takes place only in" one direction at a 
time. Short switchover times are important as this will 
increase the system efficiency. 



Exhibit 2, p. 679 





Cantel Mohitex- 


"I 

10S6 - A 296 5173/04 Ue 




teAi. 1*. l 7 ..T., 

1990-02-25 A | MTS18.2 




2.2 SPEECH TRANSMISSION 






The speech transmission mode is only reached after a 
request from either a mobile or a fixed terminal. 




After a request for speech communication the base station 
allocates a radio channel and sends an order 'to the mobile 
station to switch over to that channel (separate, transmit 
and receive frequencies). 




No squelch function is to be used during speech 
communication. 




The muting of the audio paths is released during speech 
communication. If r however, a data signal is detected 
during the speech, the audio paths to be muted 
immediately. This will for example occur when a data 
message is received during ongoing speech conversation. 




2.3 TRANSMITTER CONTROL 






2.3.1 Frequency 






The transmitter frequency 
unit. 


is controlled by the control 




For information about frequency band and channel numbering 
plan to be used, please refer to document Rl-06. 




2.3.2 Carrier 






The carrier on/off condition is controlled by the control 
unit during data transmissions. During speech transmission 
the carrier on/off condition is controlled by the manually 
operated transmit/receive switch. 




Requirements of dynamic output power control can be made. 
. In such a case, these are stated in reference Rl-06. 




There is to be a control circuit, independent of all other 
logic,, which prohibits the continuous transmission of 
carrier for longer periods than 10 minutes. 




2.3.3 Audio muting 






The voice signal to the transmitter to be muted during 
data transmissions. 
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2.4 RECEIVER CONTROL 

2.4.1 Frequency 

The receiver frequency is controlled by the control unit. 

For information about frequency band and channel numbering 
plan to be used, please refer to document Rl-06. 

2.4.2 Squelch control 

There must be no squelch function in the receiver. 

2.4.3 Signal strength indication 

The received signal strength level is used in the roaming 

algorithm for selection of base station. 

Please refer to chapter RECEIVER in this document which 

includes a specification of the signal strength 

indication. 

2.4.4 Audio muting 

Whenever a data signal is detected, e.g detection of frame 
synchronization, the receiver voice output should be 
muted. 
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3 PERFORMANCE AND TECHNICAL REQUIREMENTS 



3 . 1 GENERAL 



For definitions and measurement methods, please refer to 
Appendix A. 



3.1.1 Frequency range 

For information about which frequency band and channel 
numbering plan etc that will be used, please refer to 
document Rl-06. 



3.1.2 Frequency error 

■ The frequency error-of— the transmitter and receiver shall 
not exceed {+){-) 1.5 ppm. 



Exhibit 2, p. 682 



Cantel Mohitex~ 



j 1056 - A 296 5173/04 Ue 

i 3>-= J» Ta^ 1?. 

j 1990-02-25 A j MTS18.2 



3.1.3 Data transmission 
3.1.3.1 Modulator 



Logic 


Level 


NRZ 


Lowpass 




VCO 


seq. 


shifter 


waveform 


filter 





J 



Figure 1. Block diagram of the method' of modulation. 

The modulation type is binary digital baseband filtered FM 
at a speed of 8 kbit/s. The method of modulation is shown 
in principle in Figure 1. The logic sequence to transmit 
is converted to a binary NRZ waveform by a level shifter 
and the NRZ waveform is filtered by a lowpass filter with 
...linear... phase-characteristic. 

The filtered waveform is applied as control incut to a 
VCO, a voltage controlled oscillator. The lowpass filter 
reduces the deviation of the modulator for the high- 
frequency components of the binary modulating signal and 
thereby reduces the out of band emission of the 
transmitter. 

A sequence of logic l's should yield a transmitter 
frequency 2.0 kHz higher than the channel center 
frequency. A sequence of logic 0's should vield a 
transmitter frequency 2.0 kHz lower than the channel 
center frequency. That is the modulation index is 0.5. 

The filter (or the equivalent filter in case of an other 
implementation) shall be a low pass filter with linear 
phase characteristic and a 3-dB frequency of 2.4 kHz. At a 
frequency two (2) times the 3-dB frequency the attenuation 
of the filter shall be 12 dB, and at a frequency four (4) 
times the 3-dB frequency the attenuation of the filter 
shall be 48 dB. The high frequencv roll-off of the filter 
must be at least 40 dB/octave. A high frequency 
attenuation of 70 dB is considered sufficient. Figure 2 
shows the amplitude response of the filter. The frequency 
modulator should be of a wide band linear type with 
frequency independent response in the frequency range 0 - 
4 kHz or otherwise compensated in the baseband filter. 
An eye diagram of the transmitted signal is shown in 
Figure 3. 
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Figure 3. 


Eye diagram. 






A preferred implementation of the baseband processing is 
oversampling of the bit-stream 4-8 times and digiral 
filtering in a FIR (finite impulse response) filter with 
symmetric coefficients. This type of implementation can be 
realized by simple table look-up in a PROM. 


The modulation rate is 8 kbits per second. The frequency 
error of the bitrate clock should not exceed. +-10 ppm. 
The error of the modulation index should not exceed +- 5 
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3.1.3.2 Demodulator 



The demodulator should be of non-coherent type. A simple 
decision feedback or sequence detector should be used to 
resolve the small receiver eye opening of two subseouent 
bit transitions. A required bit error rate (BER) curve as 
a function of receiver input in a static receiver noise 
limited situation is shown in Figure 4. 

The performance requirement of the comDlete receiving 
equipment when connected to a reference data transmitter 
is that the decoded block error rate should be less than 
0.1 at the reference RF input signal level. At an RF input 
signal level 30 dB above the the reference level, the 
decoded block error rate should be less than 0.0001. 

It is essential that the demodulator keeps the synchronism 
with the incoming bit-stream during an entire message, ' 
even under disturbed conditions, in order to avoid 
repetition of other blocks than those which were actually 
disturbed. " " ~ ' 



BER 
1E-1 





1E-2 






1E-3 






Figure 4. 


115 112 109 Receiver input (-dBm) 
Bit error rate versus receiver input level. 
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3.1.3.3 Start of data modulation 

Data modulation must not start until the carrier frequency 
is within its 200 Hz from its steady state value and che 
carrier power is within 2 dB from its steady state value. 

The transmitter carrier should be on for 5 -0/+5 ms before 
the start of transmission (frame head). 



3.1.3.4 Receive/transmit switching times 

The switching time from receive to transmit condition to 
be less than 20 ms including CPU handling time. 

The switching. time from transmit to receive condition to 
be less than 20 ms including CPU handling time. 



3.1.4 Test terminals 

Please note that the transceiver input/output terminals 
for voice must be accessible. 

An interface according to the "machine interface" defined 
in reference Rl-19, must be available during testing. 



'3.1.5 Test modulation 

Short and long frames as defined in the link layer will be 
used during tests of data transmission. 

It should be possible to' force the modem to continuously 
transmit a sequence as specified in the national 
requirements for out of band emission testing. 

It should be also be possible to force the modem to 
continuously transmit the scrambling sequence that is 
specified in Physical Layer Specification of the mobile 
terminal. 

Normal audio test modulation is a 1 kHz test tone at such 
a level that the resulting deviation is +- 1.5 kHz. 
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3.2 TRANSMITTER 

For definitions and measurement methods, please refer to 
Appendix A. 



3.2.1 Carrier power 

The nominal output power is stated in reference Rl-06. 
Requirements of dynamic output power control can be made. 
In such a case, these are also stated in reference Rl-06. 

Under normal, test conditions and independent of selected 
channel the carrier output power during carrier on 
condition to be within "(+)(-) 1,5 dB of the nominal output 
power. Under extreme test conditions the carrier output 
power to be within +2 dB and -3 dB of the nominal output 
power . 

When the transmitter is in the carrier off condition, the 
carrier output power should not exceed 0,25uW. 



The transmitter to be able to withstand load tests as 
described below: 

-the change in the transmitter output power should not 
exceed 2 dB during a load test when. the transmitter is 
loaded with a resistive load giving a standing wave ratio 
of 2. The test to be done at normal test conditions 
during 5 minutes of continuous transmission. 

-without being damaged the transmitter should be able to 
withstand the same test at extreme test conditions. 

-without being damaged the transmitter should be able to 
transmit for a period of 1 minute with the antenna 
terminal left open. 

-the last mentioned test to be repeated with the antenna 
terminal short-circuit. 
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3.2.2 Carrier rise and fall time 

The carrier rise time and carrier fall time are included 
in the transmit-receive and receive-transmit switching 
times. Please refer to chapter "Heceive/transmit switching 
times' in this document. 

3.2.3 Channel switching time 

The channel switching time should not exceed 30 ms. 
3 -2.4 Frequency deviation 

3.2.4.1 Maximum permissible deviation 

The maximum permissible frequency deviation to be 
(+)(-)2.S kHz. 

3.2.4.2 - Data modulation 

A long sequence of logic l's (O's) should produce a 
carrier frequency deviation of +{-, for O's] 2.0 kHz 
+- 0.1 kHz. 

3.2.4.3 Audio modulation 

The normal audio test tone will produce a deviation 
of +- 1.5 kHz. 

3.2.4.4 Audio frequency response 

The audio frequency response, measured through the audio 
signal input terminal, should have a 6 dB/octave pre- 
emphasis between 300 Hz to 2500 Hz. For frequencies higher 
than 3000 Hz, the frequency response should have a roll- 
off of at least 30 dB/octave. 
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Figure 5. Frequency deviation relative to 1 kHz at 
constant input level. 



3.2.5 Adjacent channel power 

The adjacent channel power should not exceed the value 
specified in the national technical requirements, in case 
such a value is specified in the national technical 
requirements. 



3.2.6 Harmonic distortion 

The harmonic distortion factor should not exceed 5%. 



3.2.7 Residual modulation 

The residual modulation should not exceed - 40 dB, 
measured with a psophometric filter. 

The residual modulation should not exceed - 20 dB, 
measured without filter. 
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3.2.8 Modulation due to vibration 

The modulation due 'to vibration should not exceed -30 dB 
measured by a r.m.s. voltmeter and with a psophometric 
filter. 

Without the psophometric filter and measured by a peak-to- 
peak voltmeter the modulation should not exceed -14 dB. 



3.2.9 Audio muting 

An input muting device controlled by the control unit 
should be provided. The muting to be capable of causing at 
least 40 dB attenuation in the voice path. Data 
transmission is not to start until the muting has reached 
an attenuation of 40 dB. 
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3.3 RECEIVER 

For definitions and measurement methods, please refer to 
Appendix A. 



3.3.1 Channel switching time 

The channel switching time should not exceed 30 ms 
including data signal detection time. 

3.3.2 Squelch opening and closing levels and delays 
There must be no squelch function in the receiver. 

3.3.3 Signal strength indication 

The signal strength to be indicated by the receiver to the 
control unit. 

The indicated range to be : 

RF-level . 0-50 dBuV eraf with a monotonic output 

and absolute accuracy of 

+-(2 +10 % of actual value) dBuV eraf. 

The time constant to be 1 ms. 



3.3.4 RF sensitivity 

The receiver sensitivity (speech) not to exceed 0 dBuV emf 
under normal test conditions and + 4 dBuV emf under 
extreme test conditions. 



The reference signalling sensitivity (data) not to exceed 
0 dBuV emf under normal test conditions , and 3 dBuV emf 
under extreme test conditions. 

The multipath signalling sensitivity (data) must not 
exceed 12 dBuV emf. This measurement is oniy done under 
normal test conditions. • 
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3.3.5 Adjacent channel selectivity 

The receiver shall comply with applicable national 
technical requirements. 



3.3.6 Spurious response rejection 

The receiver shall comply with applicable national 
technical requirements. 



3.3.7 Co-channel rejection 

The measurement is made with the wanted signal at an input 
level of +10 dBuV emf . 

The co-channel, rejection level at any frequency 
displacement of the unwanted signal within the specified 
range to be greater than -2 dBuV emf. 



3.3.8 Intermodulation response 

The receiver shall comply with applicable national 
technical requirements. 



3.3.9 Blocking 

The receiver shall comply with applicable national 
technical requirements. 



3.3.10 Amplitude characteristic of the receiver 

For the specified change of radio frequency input level, 
the change of the audio output level should not exceed 3 
dB between the maximum and minimum output levels. 



3.3.11 AM-suppression 

The AM-suppression should not be less than. 30 dB. 



3.3.12 Audio frequency response 

The audio frequency response, measured at the audio output 
terminal, should be within the limits as shown in the 
figure below. 
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300Hz 1000Hz 3000Hz 

Figure 6 . Audio power relative to 1kHz at constant 
frequency deviation. 



3.3.13 Harmonic distortion 

At all audio frequencies used in the measurement and under 
all test conditions the harmonic distortion factor should 
not exceed 5%. 



3.3.14 Noise and hum 

The receiver "noise and hum" ratio should not exceed -40 
dB measured by a- r.ra.s. voltmeter and with a psophometric 
filter. 

Without the psophometric filter and measured by a peak-to- 
peak voltmeter the "noise and hum" ratio should not exceed 
-20 dB. 
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3.3.15 Audio output due to vibration 

The noise and hum ratio of the receiver due to vibration 
should not exceed -30 dB measured by a r.m.s. voltmeter 
through a psophometric filter. 

Without the filter and measured by a peak-to-peak 
voltmeter the the ratio should not exceed -14 dB. 



3.3.16 Audio muting 

An output muting device controlled by the control unit to 
be provided. The muting device to be capable of causing at 
least 40 dB attenuation in the voice path. 
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4 MOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 

Rl-06, 6, 7, 8, 13 
Rl-19, 12 



Below are the reference designations listed. 



Reference Section 

Rl-01 •• Arrangement of the documents 

Rl-02 MOBITEX System description 

Rl-03 General description of terminals 

Rl-04 Terminology 

Rl-05 References 

Rl-06 Network operator information 

Rl-08 Application layer 

Rl-09 Network layer 

Rl-11 Interface requirements, fixed terminals 

Rl-12 Other requirements, fixed terminals 

Rl-16 Link layer, mobile terminals 

Rl-17 Physical layer mobile terminals 

Rl-18 Radio equipment, mobile terminals 

Rl-19 Other interfaces, mobile terminals 

R1-.20 Other requirements, mobile terminals 
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MOBITEX MOBILE RADIO EQUIPMENT 

12.5 kHz, 900 -MHz . 

Appendix A, Measurement methods 



1 INTRODUCTION 

This document is an Appendix to MOBITEX TERMINAL 
SPECIFICATION - RADIO EQUIPMENT. It consists of 
requirement definitions and measurement method 
descriptions. 

The measurement values applies to 12,5 kHz channel spacing 
in the 900 MHz frequency band. 

The document describes measurement methods for several 
data transmission speeds. Therefore, measurements without 
specified requirement procedures in the main document can 
be found. These should be ignored. 

The equipment specified in this document should also meet 
with basic requirements set up in national regulations for 
radio transmitters and radio receivers. 
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2.1 SYSTEM MEASUREMENTS 



2.1.1 Receive to transmit switching time 
Definition: 

The switching time from receive to transmit condition is 
defined as the elapsed time from the end of an incoming 
frame with the response flag set, to the beginning of the 
response, i.e. the data signalling starts (see main 
document "Start of data modulation" ) . 

2.1.2 Transmit to receive switching time 
Definition: 

The switching time from transmit to receive condition is 
defined as the elapsed time from end of the last frame in 
a message sent by the transmitter, until the receiver is 
capable of detecting incoming data signals. 

2.1.3 . Channel switching time 
Definition: 



The channel switching time 
from the end of a received 
the receiver is capable of 
new channel. 



2.1.4 Frequency error 
Definition: 



is defined as the elapsed time 
order to change channel, until 
detecting data signals on the 



The frequency error of the transmitter is the difference 
between the measured carrier frequency and its nominal 
value . 



Method of measurement: 

The carrier frequency should be measured in the absence of 
modulation with the transmitter connected to an artificial 
antenna. 

The test should be made under normal and extreme test 
conditions. 



Exhibit 2, 





Cantel Mobitex- 


A/1056 - A 296 5173/01 Ue 




"1990-02-23 l3 C 1 MTS18A.1 




2.2 TRANSMITTER MEASUREMENTS 




2.2.1 Carrier power 






Definition: 






The transmitter carrier power is the mean power delivered 
to the artificial antenna during a radio frequency cycle 
in the absence of modulation. 




Method of measurement: 






The transmitter should be connected to an artificial 
antenna and the power delivered to this artificial antenna 
should be measured. 




The measurements should be made under normal and extreme 
test conditions.- 




2.2.2 Maximum permissible fr-eouency deviation 




Definition: 






The frequency deviation is the maximum difference between 
the instantaneous frequency of the modulated radio 
frequency signal and the carrier frequency in the absence 
of modulation. 




Method of measurement: 






The frequency deviation should be measured at the output 
of the transmitter connected to an artificial antenna, by 
means of a deviation meter capable of measuring the 
maximum deviation, including that due to. any harmonics and 
intermodulation products which may be generated in the 
transmitter. 




2.2.3 Audio frequency response 




Definition: 






The audio frequency response is the frequency deviation of 
the transmitter carrier as a function of -modulation 
frequency at a constant level of the modulation signal. 




Method of measurement: 






A modulation signal at a frequency of 1000 Hz and adjusted 
to such level that a frequency deviation of (+)(-)0,5 kHz 
is obtained, is applied to the transmitter. The frequency 
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of the modulation signal is then varied between 300 Hz and 
25 kHz, its level being <ept constant. The connection 
values of frequency deviation and modulation freauencv 
should be determined. 


2.2.4 Adjacent channel 


power 


Definition: 





The adjacent channel power is that part of the total power 
output of a transmitter under defined conditions of 
modulation, which falls within a sDecified oassband 
centred on the nominal frequency of either of the adjacent 
channels. This power is the sum of the mean power produced 
by the modulation, hum and noise of the transmitter. 



Method of measurement: 

The adjacent channel power should be measured with a power 
measuring receiver which fulfills the requirements given 
in the CEPT recommendation T/R 24-1, The transmitter 
should be operated at the nominal carrier power under 
normal test conditions. The output of the transmitter 
should be linked to the input of the receiver by 
connecting device such that the impedance presented to the 
transmitter is 50 ohms and the level at the "receiver" 
input is appropriate. 

The transmitter should be modulated with a signal of 1250 



The signal of 1250 Hz should be adjusted to a level 20 dB 
higher than that required to produce (+)(-)l,5 kHz 
deviation. The "receiver" should be tuned to the nominal' 
frequency of the transmitter and the variable attenuator 
in the "receiver" should be adjusted to a vaiue p dB such 
that a meter reading of the order of 5 dB above the 
"receiver" noise level is" obtained. 

The "receiver" should then be tuned to the nominal 
frequency of one of the adjacent channels and the variable 
attenuator should be adjusted to a value q dB such that 
the same meter reading is obtained. 

The measurement should be repeated with normal data test 
modulation (paragraph Test modulation, in the Main 
document ) . 

The ratio of adjacent channel power to carrier power is 
the difference between the attenuator settings p and q. 
The adjacent channel power is determined by applying this 
ratio to the carrier" power. 
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2.2.5 Harmonic distortion 
Definition: 

The harmonic distortion factor of a transmitter modulated 
by an audio frequency signal is defined as the ratio, 
expressed as a percentage, of the r.ra.s. voltage of all 
the harmonic components of the fundamental audio frequency 
to the total r.m.s. voltage of the signal after linear 
demodulation. 

With the method described below, when a distortion meter 
is used, the hum and noise components are included in the 
distortion measurement. 



Method of measurement: ..=. -.- 

The radio frequency signal produced by the transmitter is 
applied, by means of a suitable coupler, to a linear 
demodulator equipped with a de-^emphasis network of 6 dB 
per octave. 

The radio frequency signal to be modulated successively at 
frequencies of 300, 500 and 1000 Hz frequency to (+)(-) 1.5 
kHz deviation. 

The harmonic distortion factor of the audio frequency 
signal is measured at all the frequencies given above. 



2.2.6 Residual modulation 
Definition: 

The residual modulation of the transmitter is the ratio, 
expressed in dB, of the audio frequency noise level 
produced after radio frequency signal . demodulation, in the 
absence of modulation, by the wanted signal, by the 
spurious effects of the power supply system, by the 
modulator or by other causes, to the audio frequency level 
produced by normal test modulation applied to the 
transmitter. 

Method of measurement: 

a) The normal test modulation is applied to the 

transmitter. The RP signal produced by the transmitter 
is applied by means of a suitable coupler to a -linear 
demodulator. 
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The demodulator is equipped with a de-emphasis network 
of 6 dB per octave. 

All precautions .should be taken to prevent the 
measurement results from being affected by emphasis at 
the low audio frequencies of the internal linear 
demodulator noise. 

Measurements to be carried out on the demodulator 
output signal by means of an r.m.s. voltmeter equipped 
with psophometric filter network described in CCITT 
Recommendation P. 53 .A. 

The modulation is then removed and the level of the 
residual audio frequency output signal is again 
measured. 



b) The same method as a) above but without the 
psophometric filter at the output. 

.. J&.,J;.M.s, case .the measurements are carried out by means 

of a peak-to-peak voltmeter. 



2.2.7 • Modulation due to vibration 
Definition: 

Modulation due to vibration denotes the ability of the 
transmitter to withstand influence on the radio frequency 
output signal by mechanical vibrations. 



Method of measurement: 

The residual modulation is .measured in accordance with 
5.2.2. The transmitter should during the test be vibrated 
in each of three directions: 

10 - 100 Hz 1 ra/s 2 

sweep rate 1 octave per minute 



Exhibit 2, p. 



Cantel Mobitex* 



A/1056 - A 296 5173/01 Ue 



1990-02-23 C 



2.3 RECEIVER MEASUREMENTS 
2.3.1 RF sensitivity 
Definition: 

The maximum usable sensitivity of the receiver is the 
minimum level of signal (eraf) and field-strength 
respectively at the receiver input, at the nominal 
•frequency of the receiver, with normal test modulation 
which will produce: - 

an audio-frequency output power of at least 50% of the 
rated power output and 

a SND/ND ratio (S=signal, N=noise, D=distortion) of 20 dB, 
measured at the receiver output through a telephone 
psophoraetric weighting network as described in CCITT 
Recommendation P.53-A. 

'" Note: The characteristics of the 1" kHz band-stop filter - 
used in SND/ND measurements should be such that at 
the output the attenuation at 1 kHz will be at least 
40 dB and at 2 kHz will not exceed 0.6 dB. The 
filter characteristics should be flat within 0.6 dB 
over the ranges of 20 Hz to 500 Hz and 2 kHz to 4 
kHz. In the absence of modulation of the total noise 
power at the audio-frequency output of the receiver 
under test. 

The reference signalling sensitivity data is the level and 
field-strength respectively of a radio frequency input 
signal at the nominal receiver frequency and modulated 
with the normal coded test signal or pseudo- random bit 
sequence which will produce a successful calling ratio of 
80% for signalling systems with a specific response as 
output and a bit error ratio of 0.01 for. data transmission 
systems with a bit stream as output respectively. 

Measurement methods: 

A signal of carrier frequency equal to the nominal 
frequency of the receiver and with normal test modulation 
shall be applied to the receiver input terminals. An audio 
frequency output load and a distorsion factor meter 
incorporating a 1 kHz band-stop filter and a psophometric 
telephone weigthing network shall be connected to the 
receiver output terminals. Where possible, che receiver 
volume control shall be adjusted to give at lease 50% of 
the rated output power. The test signal input level shall 
be reduced until a SND/ND ratio of 20 dB is obtained. The 
test signal input level under these conditions is the 
maximum usable sensitivity. The measurement shall be made 
under normal test conditions and extreme test conditions. 
Under extreme test conditions, a variation of the receiver 
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output power of (+)(-) 3 dB from the value obtained under' 
normal test conditions may be allowed. 

A signal of carrier frequency equal to the nominal 
frequency of the receiver and modulated with the normal 
coded test signal or a psuedo-random bit sequence shall be 
applied to the receiver input terminals. The level of this 
signal shall be such that a successful calling ratio of 
SCR = 80%, and a bit error ratio of BER =0.01 respective- 
ly is obtained. The reference signalling sensitivity 
(data) is the maximum level of the levels recorded for SCR 
= 80% and BER = 0.01. 



The multipath signalling sensitivity is the rms value of 
the level of a Rayleigh fading input signal at the nominal 
receiver frequency and modulated with the normal coded 
test signal or pseudo-random bit sequence which will 
produce a sucessful calling ratio of 80% and a bit error 
rate of 0.01. The measurements shali be carried out with a 
Rayleigh fading simulator set for a simulated vehicle 
speed of 90 km/h and repeated for ,a simulated vehicle 
speed of 50 km/h and 10 km/h. The reference multipath 
signalling sensitivity (data) is the maximum neccessary 
level of the multipath measurements. 



2.3.2 Adjacent channel selectivity 
Definition: 

The adjacent channel selectivity is a measure of the 
capability of the receiver to receive a wanted modulated 
signal without exceeding a given degradation due to the 
presence of an unwanted modulated signal which differs in 
frequency from the wanted signal by an amount equal to the 
adjacent channel separation, for which the equipment is 
intended. 

Method of measurement: 



Two signals should be applied to the receiver via a 
combining network. The wanted signal should be at the 
nominal frequency of the receiver and be modulated with 
normal test modulation. The unwanted signal should be at 
the nominal frequency of the upper adjacent channel and be 
modulated with a 400 Hz tone to a frequency deviation of 
(+)(-)l,5 kHz. 

Initially the unwanted signal should be switched off and 
the level of the wanted signal should be adjusted to 6 
dBuV-emf. The unwanted signal should then be switched on 
and its level adjusted until the SND/ND ratio, measured at ■ 
the receiver .line output terminal through the psophometric 
filter,- is reduced to 14 dB. 
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The measurement should be repeated with the unwanted 
signal at the nominal frequency of the lower adjacent 
channel . 

The adjacent channel selectivity should be expressed as 
the lower value of the receiver input levels in dBuV emf 
of the unwanted signal for the upper and lower adjacent 
channels . 



2.3.3 Spurious response rejection 
Definition: 



The spurious response rejection is a measure of the 
capability of the receiver to discriminate between the 
wanted modulated signal of the nominal "frequency and an 
unwanted signal at any other frequency at which a response 
is obtained. 



Method of measurement: 

Two input signals should be applied to the receiver via a 
combining network. The wanted signal should be at the 
nominal frequency of the receiver and be modulated with 
normal test modulation. Initially the unwanted signal 
should be switched off and the wanted input signal 
adjusted to 6 dBuV emf. The unwanted signal should be 
switched on and modulated with a 400 Hz tone to a 
frequency deviation of (+)(-)l,5 kHz. The input level of 
the unwanted signal should be 86 dBuV emf and its 
frequency should be varied at least from 100 kHz to 2000 
MHz. 

At any frequency at which a response is obtained, the 
input level of the unwanted signal should be adjusted 
until the SND/ND ratio, measured at the line output 
terminal of the receiver ..through the psophometric filter, 
is 14 dB. 



The spurious response rejection should be expressed as the 
level in dB of the unwanted signal relative to 1 uV emf 
at the receiver input when the SND/ND ratio of 14 dB, as 
mentioned above, is obtained. 



2.3.4 Co-channel rejection 
Definition: 

The co-channel rejection is a measure of the capability of 
the receiver to receive a wanted modulated signal without 
exceeding a given degradation due to the presence of an 
unwanted modulated signal, both signals being at the 
nominal frequency of athe receiver . 
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Method of measurement: 

Two input signals should be applied to the receiver via a 
.combining network. The wanted signal should have normal 
test modulation. The unwanted signal should be modulated 
with a frequency of 400 Hz to a frequency deviation of 
( + )'(-)l»5 kHz. Both input signals should be at the nominal 
frequency of the receiver and the measurement should be 
repeated for displacements of the unwanted signal up to 
{+)(-)l»5 kHz offset frequency of the nominal frequency. 

Initially the unwanted signal should be switched off and 
the level of the wanted signal should be adjusted to +6 
dBuV emf.The unwanted signal should then be switched on. 

The level of the unwanted signal should be adjusted until 
the SND/ND ratio, measured at the line output terminal of 
the receiver through the psophometric filter, is reduced 
to 14 dB. 

The., co-channel rejection should be expressed as the ratio 
in dB of the level of the unwanted signal to the level of 
the wanted signal at the receiver input for which. SND/ND = 
14 dB at the receiver line output terminal occurs. 



2.3.5 Intermodulation response 
Definition: 

The intermodulation response is a measure of the 
capability of the receiver to receive a wanted modulated 
signal without exceeding a given degradation due to the 
presence of two or more unwanted signals with a specific 
frequency relationship to the wanted signal frequency. 



Method of measurement: 

Three signal generators. A, B and C, should be connected 
to the receiver via a combining network. 

The wanted signal, represented by signal generator A, 
should be at the nominal frequency of the receiver and 
should have normal test modulation. 

The unwanted signal from signal generator B should be 
unmodulated and adjusted to the frequency separated by 25 
kHz above the nominal frequency of the receiver. 

The second unwanted signal from signal generator C should 
be modulated with a frequency of 400 Hz with a deviation 
of 1,5 kHz and adjusted to the frequency 50 kHz above the 
nominal frequency of the receiver. 
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The amplitude of the wanted input signal should be 
adjusted to 6 dBuV emf. The amplitude of the' two unwanted 
signals should be maintained equal and should be adjusted 
until the SND/ND ratio at the receiver output, . 
psophometr ically weighted, is reduced to 14 dB. 

The frequency of signal generator B should be adjusted 
slightly, if necessary, to produce the maximum degradation 
• of the SND/ND ratio. The level of the two unwanted test 
signals should be readjusted to restore the SND/ND ratio 
of 14 dB. 

The measurement should be repeated with the unwanted 
signal B at 25 kHz below that of the wanted signal and the 
frequency of the unwanted signal C at 50 kHz below that of 
the wanted signal. 

The intermodulation response level is the receiver input 
level in dB produced by each of the two unwanted Signal 
generators relative to 1 uV emf. 



2.3.6 Blocking 
Definition: 

Blocking is- a change (generally a reduction) in the wanted 
output power of a receiver or a reduction of the SND/ND 
ratio due to an unwanted signal on another frequency. 

Method of measurement: 

Two input signals should be applied to the receiver via a 
combining network. The wanted signal should be at the 
nominal frequency of the receiver and should have normal 
test modulation. Initially the unwanted signal should be 
switched off and the input level of the wanted signal 
should be adjusted to 6 dBuV emf. 

The output power of the wanted signal at the line output 
terminal of the receiver should be adjusted to the nominal 
output level. Then the unwanted signal should be switched 
on. The unwanted signal should be unmodulated,, and its 
frequency should be varied between +1 MHz and +10 MHz, and 
also between -1 MHz and -10 MHz, relative to the nominal 
frequency of the receiver. The input level of the unwanted 
signal, at all frequencies in the specified ranges, should 
be so adjusted that the unwanted signal causes: 

a) a reduction of 3 dB in the audio frequency output power 
of the wanted signal, 

or 

b) a reduction of the SND/ND ratio to 14 dB, measured 
.through a psophometric filter. 
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whichever occurs first. 






This input level is the blocking level" at the frequency 
concerned. 




2.3.7 Amplitude characteristics 




" Definition: 






The amplitude characteristics of the receiver is the 
relationship between the radio frequency input level of 
specified modulated signal and the audio-frequency level 
at the receiver output. 




Method of measurement: 






A test signal at a level of 6 dBuV eraf at the nominal 
frequency of the receiver and having normal test 
modulation should be applied to . the receiver input. The 
audio frequency power at the line output should be 
adjusted to the nominal level. The .input signal should be 
increased to 100 dBuV emf , and the audio frequency output 
level should again be measured. 




2.3.8 AM-suppression 






Definition: 






AM-suppression is the capability of the receiver to 
suppress amplitude modulated signals. It is expressed as 
the ratio in dB of the audio power at the line output 
terminal with normal test modulation to the audio power 
with a specified amplitude modulation. 




Method of measurement: 






A test signal at a level of 20 dBuV emf and 50 dBuV emf at 
the nominal frequency of the receiver to be applied to the 
receiver input successively. The signal should initially, 
have normal test modulation and the voice output terminal 
power should be set to the nominal output level. The 
normal test modulation should then be replaced by 
amplitude modulation to 30% with a 1000 Hz tone. The audio 
power should again be measured. It may be necessary to 
make this measurement with a selective voltmeter. 




2.3.9 Audio frecruency response 




Definition: 
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The audio frequency response of the receiver expresses the 
variation in. the audio- power at the line output terminal 
as a function of the modulation frequency of the input 
signal. 



Method of measurement: 

A test signal at a level of 60 dBuV emf at the nominal 
frequency of the receiver and having normal test 
modulation to be applied to the receiver input. 

The audio power to be adjusted to 50 % of the rated output 
power. This setting is not to be altered during the test. 

The frequency deviation at 1000 Hz then should be reduced 
to (+)(-)0,5 kHz and maintained constant while the 
modulation frequency is varied at least between 300 Hz and 
5000 Hz. 

-• rhe~"m^asarement is repeated with the test signal- ' 
successively at plus and minus 1,25 kHz from the nominal 
frequency' of the receiver. 



2.3.10 Harmonic distortion 
Definition: 

The harmonic distortion factor at the voice output 
terminal of the receiver is defined as the ratio, 
expressed as a percentage, of the r.m.s. voltage of all 
the harmonic components of the fundamental audio frequency 
to the total r.m.s output voltage. 

With the method of measurement described below in case a 
distortion meter is used, the hum and noise components are 
included in the distortion measurement. 



Method of measurement: 

Test signals of 60 dBuV emf and 100 dBuV emf at the 
nominal frequency of the receiver should be applied 
successively to the receiver input. 

In each measurement the audio power at the voice output 
terminal should be adjusted to the nominal output level. • 

The test signal to be modulated successively with 300, 500 
and 1000 Hz tones to (+)(-) 1,5 kHz frequency deviation 
and the harmonic distortion is measured at each frequency. 

Dnder extreme test conditions, tests to be carried out at 
the nominal frequency of the receiver as well as at plus 
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and minus 1,25 kHz from the nominal frequency. In. this 
case the input signal is modulated only. with a 1000 Hz 
tone to a ftequency deviation of (+)(-) .1,5 kHz. 



2.3.11 Noise and hum 



Definition: 



The "noise and hum" of the receiver is the . ratio, expressed 
in decibels, of the. audio frequency noise and hum level 
resulting from the spurious effects of the power supply 
system or from other causes to the audio frequency level 
produced by RPrsignals as specified below and applied 
to the receiver input. 

Method of measurement: 

a) A test signal at a level of 30 dBuV emf at the nominal, 
frequency of the receiver and having normal test 

modulation, should be applied to the receiver input.' A" 

psophometric filter to be connected at the voice output 
terminal. The audio power to be adjusted to nominal 
level. 

The output voltage is measured with an r.ra.s. 
voltmeter . 

The modulation is then removed and the audio power 
measurement is repeated. 

b) The same method as in case a) above, but without the 
psophometric filter and using a peak-to-peak voltmeter 
for the measurement. 



2.3.12 Audio output due to vibration 
Definition: 

Audio output due to vibration denotes the ability of the 
receiver to withstand influence on a received radio 
frequency signal by mechanical vibrations. 



Method of measurement: 

The noise and hum of the receiver is measured in. 
accordance with 5.3.6. The receiver should during the test 
be vibrated in each of 3 directions. 

10 - 100 Hz 1 m/s 2 

sweep rate 1 octave per minute 
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During the vibration the radio frequency test signal 
should be unmodulated and the level of the receiyer output 
signal should be measured. 
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2.4 MEASUREMENT ACCURACY 

The measurement instrumentation should have at least the 
accuracy given below: 



D.C voltage 

A.C mains voltage 

A.C mains frequency 

Audio-frequency voltage, power, etc. 

Audio-frequency 

Distortion and noise, etc of audio 
frequency generators 

Radio frequency 

Radio frequency voltage 

Radio-frequency field strength 

Radio-frequency carrier power 

Impedance of artificial loads, 
combining units,, cable, plugs, 
attenuators, etc. 

Source impedance of generators and 
input impedance of measuring receivers 

Attenuation by attenuators 
Temperature 

Humidity 

Time 



(-}!% 

(-)3% 

(-)0,5% 

(-)0,5 dB 

(-)0,1% 

(-)0,5% 

(-)20 Hz 
(-)2 dB 
(-)3 dB 
(~)5% 
(-)5% 



(-)0.5 dB 

(-)i°c 



(")5% 
(-)10% 
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MOBITEX 

Other interfaces, mobile terminal 
and fixed terminal 



ABSTRACT 

This document specifies the interfaces between the HOBITEX 
network and a mobile or fixed terminal connected to the 
network. 
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1 INTRODUCTION 
1.1 GENERAL 

The purpose of this specification is to give well defined 
interfaces for the connection of application equipment. This 
specification .will serve as a recommendation for the mobile 
terminal market. 

NOTE: The Radio/MCU must be type-tested with a terminal of 
"masc" type. A minimum number of commands (defined by 
document Mobitex ASyncronous Communication, APPENDIX 
A, Commands) are then required. 
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The picture below shows the mobile terminal system parts. 



MOBILE TERMINAL 



AODIO-EQOIPMENT | 



Hop-terminal 



MOBILE TERMINAL 



complete equipment 

mobile control unit 

equipment like mic/speaker , handset 

terminal for operators 

equipment like emergency receiver, emergency 
button 



2.1 Terminal interface 

Asynchronous, serial data transmission. Permitted transmission 
rates are 600, 1200, 2400, 4800 and 9600 Baud. However, for 
"masc" type terminals 600 baud is not permitted. Default value 
is 1200 Baud. In MOT it must be possible to set any of these 
baud .rates by hardware switches or alike. It must be possible 
to set the baud rate of each .output separately. Normally 1 
start bit, 8 data bits, 1 stop bit and no parity is used. 
However, masc type terminals should use 7 data bits and even 
parity. 

2.1.1 Printer/data collection unit 

Interface designed to connect a printer or any other character 
(text) oriented terminal. It can also be used for data 
collection units. This interface must be combined with one or 
more of the other terminal interfaces. The 7 most significant 
bits are coded according to MOBITEX TEXT CODE, see reference 
Rl-06. The eighth bit is set to logical zero. 
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2.1.2 Terminal with small display 

Designed for connection to a unit with a limited text display 
area and from which the. operator can enter numbers, status 
messages and text including simple text editing. The editor is 
placed in MCU. Also the audio equipment and the manual mode of 
the radio equipment can be handled from this unit. Character 
oriented format {as above) is used. 



2.1.3 ANSI terminal 

For connection of asynchronous full screen terminal which 
complies with terminal interface ANSI X 3.41 1964 and 
ANSI X 3.64 1979 with respect to cursor control and editing 
functions . 

From. the terminal the operator can enter numbers, status 
messages and text including text editing. The editor is placed 
in MCU. Character oriented format as above. 



2.1.4 "MASC" type terminal 

Connection of units with the capacity to handle complete data 
packets (MPAK) , e.g. a personal computer. The format is block 
oriented which means that information is' transmitted in the 
form of packets (MPAK) according to the format which is given 
in the network layer specification. Control of the complete 
mobile terminal, e.g. audio equipment and manual mode, is 
performed by special commands included in the protocol. The 
interface also contains functions for reading status parameters 
in the mobile terminal (meant for the type test) . 7 bits per 
character and even parity to be used. Permitted transmission 
rates are 1200, 2400, 4800 or 9600 Baud. 

For type testing, a masc type interface is required. In this 
case it may be implemented by external adaptors. 



2.2 Audio interface 

Connection of microphone and loudspeaker or handset. The 
interface also contains certain control functions. The handset 
can be combined with numeric and status keys. The same 
character codes as for the terminal with small display are 
used. The audio interface can also be combined with the 
terminal interface. Refer also to the application examples. 



2.3 Emergency interface 

Connection facilities for four units. Three connections are for- 
emergency buttons and one is for a receiver for receiving 
emergency transmissions generated by a portable transmitter. 
Any of these units can initiate the emergency procedure in MCU. 
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3 TERMINAL INTERFACE 

This chapter describes the interface to equipment which 
communicates with MOT in serial form. 



3.1 PHYSICAL INTERFACE 

The physical interface is the same for all terminal types. 

The terminal interface uses a 25-pole DSOB socket (female 
socket with pins) with the following configuration: 



PIN 


V.24/V.28 


V.10 category 1/V.ll 


SOURCE 


1 


supply ground 


supply ground 






2 


transmitted data 


transmitted data 


A 


DTE 


3 
4 


received data 


received data 


A 


■ MCU 


5 
6 


data set ready 


data set ready 


A 


MOT 


7 


signal ground 


signal ground 






8 




data terminal ready 


B 


DTE 


9 


system start (ground 


system start (ground) 


DTE 


10 


system start (+12V) 


system start (+5V) . 




DTE 


11 










12 


* 








13 


* 








14 


* 


transmitted data 


B 


DTE 


15 




received data 


B 


MCU 


16 .. 










17 










18 




data set ready 


B 


MCU 


19 










20 
21 


data terminal ready 


data terminal ready A 


DTE 


22 


ring ind. 


ring ind. 




MCO 


23 


* 








24 


-12V (supply) 


* 




MCU 


25 


+12V (supply) 


+5V (supply) 




MCU 



* = reserved 

Note: Pins 9, 24 and 25 differ from V.28; Pins 9, 10, 24 

and 25 differ from V.24. 

The following applies to V10: 0 or ON is when A > B 
and 1 or OFF is when B > A. 

The following applies to V28: 0 or ON is when V > 3V 
and 1 or OFF is when V < -3V. 
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The transmission rate for serial data is 600, 1200, 
2400, 4800 or 9600 baud. 

The signal "DATA SET READY" is activated as soon as 
HCD is ready to transmit. The signal to be activated 
when it is not used. 

An active signal means that the physical layer is in 
the data transmission mode. 

System Start, activating MCO from equipment not 
according to V.28. 

MCO starts up within 10 seconds when pin 9 is 
activated (ON condition) . MCU then remains on until 
all system start signals are inactivated. 
ON condition: voltage 0V - +1V; current less 

than 5 mA. 
OFF- -condition: not connected or 

voltage +2V - +15V; current less 

than 5 mA. 

System Start, activating MCO by signal according to 
V.28. 

MCU starts up within 10 seconds when pin 10 is 
activated. MCU then remains on until all system 
start signals are inactivated. • 
ON condition: voltage > 3V (see V28). 

OFF condition: not connected or 

voltage < -3V. (see V28). 

The signal "DATA TERMINAL READY" is activated as 
soon as the terminal is ready to receive. The signal 
is to be activated when not used. 

An active signal means that the physical layer is in 
the datatransmission mode. 

The signal "RING INDICATION" is used to activate the 
periferal unit. 

- 12 V/100 mA supply for connected equipment. 

+ 12 V (+ 5 V)/500 mA supply for connected 
equipment . 
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3.2 PROTOCOL FOR PRINTER/DATA COLLECTION UNITS 



General 

Interface designed to connect a printer or any other character 
(text) oriented terminal. It can also be used for data 
collection units. This interface must be combined with one or 
more of the other terminal interfaces. 



Receiving text 



To stop the data stream from MCO temporarily, the printer sends 
XOFF (DC3) to MCU and to restart the data stream it sends XON 
(DC1). 



Sending text 

Text can be sent to MCU. In MCU a complete MPAK will be created 
with sender and addressee before it is transmitted on the radio 
path. 

The connected unit stops sending when it has received XOFF 
(DC3 ) from MCU and does not start again until XON (DC1) is 
received. 



Ifeproc 
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3.3 PROTOCOL FOR TERMINALS WITH SMALL DISPLAY 



3.3.1 Receiving data 

To stop the data scream from MCU temporarily , the terminal 
sends XOFF (DC3) and co restart the data stream it sends XON 
(DG1). Received characters in the code range 32 - 126 (decimal) 
are printed out directly. Other codes are interpreted by che 
terminal according co the following tables 



CHARACTER CODE 


TERMINAL S INTERPRETATION Ur uuuiiM..L£in 


000 


NUL 




001 


SOH 




002 


STX 




003 


ETX 




004 


EOT 


- 


005 


EHQ 




006 • 


ACK 




007 


BEL 


give audible signal 


008 


as 


move cursor one step to left 


009 


HT 




010 


LP 


line feed 


011 


VT 




012 


FF 




013 - 


CR 


move cursor to beginning of line 


014 


SO 




015 


SI 




016 


DLE 




017 


DC1 


resume sending data 


018 


DC2 




019 


DC3 


stop sending data 


020 


DC 4 




021 


NAK 




022 


SIN 




023 


ETB 




024 


CAN 




025 


EM 




026 


SUB 




027 


ESC 


carry out function as defined below 


028 


FS 




029 


GS 




030 


RS 




031 


US 




127 


DEL 





AS3251SW 
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SEQUENCE 


FUNCTION WHEN RECEIVED 


<ESO[Ax 
<ESO[Bx 
<ESO[Cx 

<ESC>[Dx 

<ESC>[E 
<ESC>[H 
<ESC>[M 
<ESO[N 
<ESC>[0 

<ESC>[P 
<ESC>[Q 
<ESO[R 

<ESC>[S 
<ESC>[T 
<ESC>[0 

<ESC>{y 
<ESC>[Z 
<ESC>[[ 


place the cursor at position x 

insert character x at cursor position 

delete character at cursor and insert 

character x at end of line 

delete character at cursor and insert 

character x at beginning of line 

send user information 

send display size 

restart of terminal from MCO 

display visible <CR> 

display visible <LF> 

LED1: on (contact with system) 
(green) blinking (no contact with system) 
off (power off) 

LED2: on (external call ind. on) 
(orange) blinking (no function) 

off (external call ind. off) 

LED3: on (Manual radio mode) 
(yellow) blinking (Call indication man. mode) 
off (MOBITEX) 
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3.3.2 Sending data 

The terminal stops when it has received XOFF (DC3) from MCU and 
does not restart until JCON (DC1) is received. All characters 
are interpreted as when receiving except for the <ESC> 
sequences defined in the following table: 



SEQUENCE 


FUNCTION WHEN SENDING 


<ESOOA 


place cursor at beginning of text 


<ESC>OB 




<ESO0C 


move cursor one step to the right 


<ESO0D 


move cursor one step to the left 


<ESC>OE 


user information follows (2048 octets) 


<ESO0Hxy 


display size: x=character/line, y=no. of line^ 


<ESC>OK 


user information missing 


<ESO0M 


send message 


<ESC>OP 


LINE CONNECTION Start 


<ESC>OQ 


STATUS 


<ESC>OR 


EMERGENCY - ' 


<ESC>OW 


TELEX 


<ESC>OX 


DATEX 


<ESC>01 


copy 


<ESO0m 


lock 


<ESO0n 


LINE CONNECTION end 


<ESC>Oo 


external call indication on/off (toggle). 


<ESC>Op 


TEXT 


<ESO0q 


increase audio volume 


<ESO0r 


decrease audio volume 


<ESOOs 


loudspeaker on/off (toggle) 


<ESO0t 


cancel 


<ESC>Ou 


TELEPHONE 


<ESC>Ov 


MANUAL RADIO MODE 



When the terminal is sending, the character DEL (decimal 127) 
is interpreted as the terminal wishing to remove the character 
to the left of the cursor. 

Following ASCII codes are used to control MANUAL RADIO mode: 



Q 

W X 


channel number where x=channel number 01 - 99 


E 


squelch on/off (toggle) 


R xxxxxxx 


selective call to xxxxxxx, x = 0 - 9 


T 


transmit call tone 


y 


loudspeaker on/off (toggle) 


U 


scanning 


I 


external call indication on/off (toggle) 
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3.4 PROTOCOL FOR ANSI TERMINAL 
3.4.1 Receiving data 

To stop the data stream from MCU temporarily, the ANSI terminal 
sends XOFF (DC3) and to restart the data stream it sends XON 
(DC1). Received characters in the code range 32 - 126 (decimal) 
ace displayed directly. Other codes are interpreted by the ANSI 
terminal according to the - following tables: 



CHARACTER 


CODE 


ANSI terminal's interpretation of character 


000 


NOL 


_ 


001 


SOH 


_ 


002 


STX 




003 


ETX 




004 


EOT 




005 


ENQ 




006 


ACK 




007 


BEL 


give audible signal 


008 


BS 


move cursor one step to the left 


009 


HT 




010 


LF 


line feed 


011 


VT 




" 012 


FF 




013 


CR 


carriage return 


014 


SO 




015 


SI 




016 


DLE 




017 


DC1 


resume sending data 


018 


DC2 




019 


DC3 


stop sending data 


020 


DC 4 




021 


NAK 




022 


SYN 




023 


ETB 




024 


CAN 




025 


EM. 




026 


SUB 




027 


ESC 


carry out function as defined below 


028 


FS 




029 


GS 




030 


RS 




031 


US 
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FUNCTION WHEN RECEIVING 



<ESC>[A 

<£SC>[3 

<ESC>[C 

<ESO[D 

<ESC>[C 

<ESC>[0q 

<ESC>[lq 

<ESC>[2q 

<ESC>[3q 

<ESC>[4q 



cursor up one step 

cursor down one step 
cursor right one step 
cursor left one step 
restart of terminal from MCD 
switch off LED1 — LED4 (not ANSI) 
switch on LED1 (not ANSI) 

switch on LED2 (not ANSI) 

switch on LED 3 (not ANSI) 

switch on LED 4 (not ANSI) 



For the meaning of LED1 - LED 3 see terminal with small display. 

If additional functions are required, we recommend the use of 
functions and control sequences in accordance with 
ANSI X 3.41 1974. and ANSI X .3.64 19.7?.... 
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3.4.2 



Sending data 



The ANSI terminal stops sending when it has received XOPF (DC3 ) 
from MCU and does not" restart until XON (DC1) is received. All 
characters are interpreted as when receiving, except for the 
<ESC> sequences defined in the following table: 



SEQUENCE 


FUNCTION WHEN SENDING 


<ESC>OA 


move cursor up one step 


<ESC>OB 


move cursor down one step 


<ESOOC 


move cursor one step to the right 


<ESC>OD 


move cursor one step to the left 


<ESOOE 


<ESC>OF 




<ESC>OG 




<ESC>OHxy 


display size: x=character/line,y=no. of lines 


<ESOOI 




<ESC>OJ 




<ESC>OK 


user information missing 


<ESC>OL 




<ESC>OM 


.send message 


<ESOON 




<ESC>00 




<ESOOP 


LINE CONNECTION start 


<ESOOQ 


STATUS 


<ESC>OR 


EMERGENCY 


<ESO>OS 




<ESC>OT 




<ESOOU 




<ESC>OV 




<ESC>OW 


TELEX (not in ANSI standard) 


<ESOOX 


DATEX (not -in ANSI standard) 


<ESC>0Y. 




<ESC>OZ 




<ESC>0[ 




<ESC>0\ 




<ESC>0] 





(Continued on next page) 
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SEQUENCE 


FUNCTION WHEN SENDING 


<ESC>Oa 




<ESC>0b 




<ESO0c 




<E5O0d 




<ESC>0e 




<ESO0f 


- 


<ESOOg 




<ESC>6h 




<ESO0i 




<ESC>0j 




<ESC>Ok 




<ESC>01 


copy 


<ESO0m 


lock 


<ESC>On 


LINE CONNECTION end 


<ESC>Oo 


external call indication on/off (toggle) 


<ESO0p 


MOBITEX, start sending message 


<ESO0q 


increase volume 


^ESOOr • 


decrease volume 


<ESO0s 


loudspeaker on/off 


<ESC>0t 


cancel 


<ESOOu 


TELEPHONE 


<ESC>0v 


scroll up presentation field 


<ESC>Ow 


scroll down presentation field 


<ESC>0x 


get next message 


<ESC>0y 




<ESO0z • 




<ESO0{ 




<ESO0l 




<ESC>0} 





When the terminal is sending- the character DEL (decimal 127) is 
interpreted as the terminal wishing to remove the character to 
the left of the cursor. 
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3.5 PROTOCOL FOR "MASC" TYPE TERMINALS 

The raasc type interface is designed for connection of units 
with the capacity to handle complete data packets (MPAK see 
reference Rl-09), e.g. a personal computer. Information is 
transferred between the terminal and MCU in the form of frames, 
described in subsequent clauses. Control of the complete mobile 
terminal, e.g. audio equipment and manual mode, is performed by 
special commands included* in the protocol. The interface also 
contains functions for reading status parameters in the mobile 
terminal (meant for the type test}. 

For type testing, a raasc type interface is' required. In this 
case it may be implemented by external adaptors. For the type 
testing, only the basic commands and the type testing commands 
are required. 

A frame is formed as a message packet with unique characters 
marking the beginning and the end of the frame. Sending may be 
initiated from both sides. The information frame must be 
acknowledged with ACK before the next information frame .is 
sent. 

The characteristics of the protocol are: ' 

- All characters are coded into the 7 least- significant bits 
and bit 8 is used for even parity. 

- The error control is done by longitudinal and character 
parity check and frame length control, 

- Transparent data can be sent in hex coded data fields. 

- The protocol permits full duplex. 



3.5.1 Frame structure 



Communication takes place in the form of frames. There are two 
types of frames, information frames and control frames. The 
information frames are used to transfer commands and other 
information. The control frames are used to control the ■ 
information frame flow. 
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The Information frames are divided into the following fields 
(number of octets stated -below) : 



It [ end 1 



I start [ length I text 



The Control frames are divided into the following fields 
(number of octets stated below): 



I start I type I sequ [end | 
110-11 

The maximum frame size permitted is set up by the B-command. 
The maximum possible size is 1150 octets. This means that an 
Information frame can not have the maximum length in all 
fields. . _ .... 



- Start 

The start of a frame is denoted by the character 2. with code 
136/94/5E in octal/decimal/hexadecimal notation. 

All characters received before the start character should be 
ignored. Every start character is the beginning of a new. frame. 



- Length 

The size of the frame, in number of octets, should be written 
in this field with the ASCII codes of four hexadecimal digits. 
The least significant digit should' always be written in octet 
4. 

The size of the frame includes all octets including start and 
end characters. 

Permitted characters of length field: 0-9, A-F. 



- Text 

Text is a field which determines the meaning and the 
interpretation of the frame. The interpretation of the text 
field is carried out by a higher layer. The text field consists 
of at least 1 character and a maximum of 256 characters. 
Numeric information, e.g. command parameters, are always to be 
■given as the ASCII codes of the corresponding hexadecimal 
digits 0-P. 

Permitted characters of text field are: 

SPACE (40/32/20) to } (175/125/7D) except Std(:) and 

startcharacter ( " ) . 
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- Std (start data) 






Text and data are separated by the character : (colon 
72/58/3A) . Std should be seated even if the data field is 
empty . 




- Data 






The data field consists of data. 

The coding of the data field is carried out in hexadecimal code 
so that transparent data can be sent. Each octet of data which 
is to be coded into the data field is divided into two half 
octets with four bits- in each. Each of these four bit groups is 
then represented in the data field by the ASCII code of the 
corresponding hexadecimal digit 0-F. Thus each input. octet is 
represented by two characters (octets) in the data field. 




The data field consists of maximum 1120 characters. 
Permitted characters of data field is: 0-9, A-F. 




- Check 






Longitudinal checksum created by exclusive OR on all characters 
starting with the start character and ending with the character 
before the checkfield. The check field consists of two ASCII 
coded hexadecimal digits with the least significant digit in 
octet 2. 




Permitted characters for the check field is: 0-9, A-F 




- Type 






The type of control frame is stated with one character. The 
characters which may be used are * (S2/42/2A), ? (77/63/3F), 
! (41/33/21), # (43/35/23) or & (46/38/26). 




- Sequ (sequence number) 






The sequence number for ACK-frames. The sequence number can be 
one of the characters 0 (60/48/30), 1 (61/49/31). or - {minus, 
55/45/2D). 




- End 






The frame is terminated with the carriage return character (CR, 
15/13/OD) . A frame which is not ended with the end character 
should be "ignored. 
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3.5.2 Information frame 

Messages are sent as Information frames with an expected 
acknowledgement (ACK) . 

The text field of an Information frame has the following 
general structures 



I com SP I pa r 

>=1 0-1 >=0 

com is the command or function code. 

SP is the space character (ASCII code 40/32/20 in 

octal/decimal/hexadecimal notation) which separates the 
command from the parameters. 

par is the ASCII coded parameters or data. 

A command which sets parameter A to 587 can be coded in the 
following ways {all commands are terminated with CR) : 

"0010S A=587:50 
"0012SET A/587 :D1 

~0010S A:028BAF 028B is hex code for 587 

~000FSA:028B78 SA is a command 



Hote: The textfield can only consist of one (1) command. 
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3.5.3 Control frames 

The protocol consist of the following control frames: 

- ACK 

- NACK 

- RACK 



- ACK (Acknowledgement of a correct received frame) 
Structure: 



ACK means that the received Information frame is correct. A' 
correct frame should comply with the following: 

- starts with the start character {"*)_■ 

- contains only one colon ( : ) 

- the fields "Check" and "length" have the correct values 

- only permitted characters in text and data fields 

- no characters with parity error 

- the permitted number of characters has not been exceeded in 
any individual field or in the complete frame. 

- ends with the end character (CR) 

The field "segu" (sequence number) should alter between ASCII 
character 0 and ASCII character 1 for each frame sent, except 
when repeating the latest ACK on a RACK request. Then the same 
value as before is sent again. 

The first time an ACK is sent "sequ" should be the character 0. 
If a RACK is received before any ACK has been sent, the field 
"sequ" will be filled with the character - (minus). "Sequ" with 
the value of - (minus) is only, used when RACK is received 
before ACK has been sent the first time. 

- NACK (No acknowledgement of an incorrect received frame) 
Structure: 



NACK is to be sent if the conditions for sending ACK are not 
fulfilled and the Information frame: 

- starts with the start character (*) 

- contains only one colon ( : ) 

- has a total length of 10 characters or more 

- ends with the end character (CR) 
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Should the criteria not be fulfilled for sending ACK or NACK, 
' no reply will be given. The frame will then be repeated by the 
timeout function in the sending unit. 




If the receiving unit cannot handle the incoming data flow, 
NACK may be used to limit the flow. 




- BACK (Request for repetition of the latest sent ACK). 




Structure: 






i-i . i-i 












RACK, request for repetition of the latest sent ACK, is sent 
when no reply on the Information frame has been received within 
10 seconds. The receiver of RACK is to reply by repeating ACK 
with the latest sequence number (sequ) used. 




- SENS (link layer control) 






Structure: 






| " | # | CR | 






11 1 ; 






SENS is used to control the communication link when there is no 
traffic. The sender decides when SENS will be sent. Time • 
between 2 SENS should be at least 10 seconds. 




When sending a SENS a reply (SACK) will be received within 10 
seconds. If no reply is received within 10 seconds, a new SENS 
will be sent. When two SENS have been sent and no reply is 
received or no info-frame has been correctly transmitted, the 
communication link is supposed to be broken. A restart will be 
done by sending a B-frame. 




If SACK is received and no SE1 
ignored. 


*S has been sent, the SACK will be 




- SACK (Sens acknowledgement) 




Structure: 






1 " U J I 






111 






SACK will be sent when a controlframe (SENS) has been received. 
It should be sent at the first possible opportunity when 
nothing else is being sent. 



A292S15W 
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3.5.4 Flow control and error handling 

If the reply of an Information frame is ACK, the Information 
frame will be correctly .received. The field "sequ" is saved as 
the latest received sequ number. 

If the reply is a MACK , the Information frame will be repeated. 

If there is no redy within 10 seconds after the Information 
frame was sent, a" HACK will be sent. If there is no reply on 
the RACK, a new RACK will be sent every 10 seconds. If no ACK 
has been received within 30 seconds after the Information frame 
was sent (time-out), higher layers will be notified. However, 
the repetition of RACK will continue until interrupted by 
higher layers or by the fact that an ACK has been received. 

When an ACK is received as a reply to a RACK, the sequ number 
of this ACK will be compared with the stored sequ number of 
latest received ACK. If the numbers are equal, the Information 
frame was not received and must be repeated. If the numbers are. 
different, the Information frame was received correctly (but 
ACK was lost) and the Information frame should not be repeated. 
However, if the sequ number of the. received ACK is - (minus) 
the Information frame must be repeated. 

When the physical layer gets into datatransmission mode the 
link layer is supposed to start up. 

When one of the two interconnected units is started up, it has 
no stored value of the sequ of the latest received ACK. Neither 
does it have a value of the sequ of the latest sent ACK. To 
handle this situation and to prevent a possible doubling of the 
first frame, the following start up procedure is required: 

- The first Information frame sent should be a B-frame. This 
B-frame consists of communication parameters for raasc 
protocol(see appendix A). 

- If the sending of that B-frame leads to error handling with 
RACK, the B-frame must be repeated regardless of the value 
of the sequ field oF"the ACK response to RACK. 

The actions to be taken when receiving ACK as a response to 
RACK are summarized in the following table: 



sequ of 





rect 


iived ACI 
0 


C 

1 


sequ 
of the 
latest 
received 

ACK 


none 


repeat 


repeat 


repeat 


0 


repeat 


repeat 


no rep. 


1 


repeat 


no rep. 


repeat 
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Communication is on a full duplex line. This means that a 
message stream can be in. progress in both directions at the 
same time. Both parties may send an Information frame 
independently of each other and an Information frame may 
therefore be received when a control frame is expected 
(ACK/NACK). However, the next incoming frame will then be a 
reply as each Information frame is to be acknowledged before a 
new one is sent. The minimum time between these two frames will 
be the time set by the ' int (interval) parameter of the 3- 
coramand (minimum time between the sending of two subsequent 
frames ) . 
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3.5.5 Time diagram 

0. MCU/terminal starts up by setting protocol parameters. 

1. HCU sends Information frame 0 to terminal which sends 
acknowledge . 

.2. MCU sends Information frame 1 which is disturbed and then 
repeated after NACK from terminal. 

3.0 MCU sends Information frame 2 but it does not reach che 
terminal the first time. Information frame repeated after 
HACK and repeated ACK being che same as previous ACK 
(segu=0). 

3.1 The same as 3.0 but this time ACK(l) dpes not reach the 
sender. HACK is sent and now the repeated ACK, having a new 
sequ, indicates that the frame was received correctly. 

4. MCU and terminal sending Information frames at the same 
time. 

5. MCU and terminal doesn't start at the same time. 
5.5 MCU restarts and B-frame is repeated. 



(Number in brackets after ACK denotes sequence number) 



MCU 


masc protocol 


operator terminal 


0. 


B(len,int) 












< 


ACK(0) 










B(len,int) 




ACK(0) 




> 




1. 


Info frame 


0 












< 


ACK(l) 


.2. 


Info frame 


1 


_X > 










< — 


NACK 




Info frame 


1 














ACK(0) 


3.0 


Info frame 


2 








timeout 10 


s 








RACK 




> 












ACK(0) 




info frame 


2 












< — - — 


ACK(l) 


3.1 


Info frame 


2 














ACK(l) 




timeout 10 


s 








RACK 
















ACK(l) 
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itiasc protocol 


operator terminal 


4. Info frame 3 
time>=int \ 
ACK(l) 


> 

< — 


I-fo frante 4 
ACK(O) 


5. 


start of MCO 
B(len,int) 
timeout 10 s 
-RACK 


— — > 

— > 






ACK(O) 

timeout LO-s 
RACK 

B(len r int) 


< 

■ < 

> 

.< 


start of op. term 
B(len,int) 

ACK(-) 
ACK{0) 


5.5 start of MCU 
B(len,int) 

timeout 10 s 
RACK 

B(len,int) 


> 

/< 

> 

< 

> 


working 
ACK(O) 

ACK{0) 
ACK(l) 
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4 AUDIO INTERFACE 



This interface is intended for the connection of audio 
equipment such as microohone and loudspeaker or a handset. The 
interface also contains certain control functions. 

A simple audio equiranent can consisc of a loudspeaker and a 
microphone or a handset with holder and switches to activate 
the functions needed (hook on/off, push-to-taik) . -The nandset 
can also be a more comolex unit using serial data to _ 
communicate over the interface and including a small display 
and numeric and status keys. Some examples, are given in 
application examples. 



4.1 PHYSICAL INTERFACE 

The terminal interface uses a 15-pole DSUB socket (female 
socket with pins) with the following configuration: 



PIN 


SIGNAL. 


ACTIVE 


SOURCE 


1 
2 
3 

' 4 
5 
6 
7 

a 

9 
10 
11 
12 
13 
14 
15 


ground for earphone/loudsp 
data send 
data receive 

extern, call indie, on/off 
volume up 
volume down 

ground for control signals 

system start 

+12V 

-12V 

microphone LF 
microphone ground 
microphone hook on/off 
transmit/receive switch 
earphone/loudspeaker LF 


on = 0V 
up = OV 
down=0V 

start=0V 

lifted=0V 
t.ransm.=0V 


MCU 

audio equipment 
MCU 

audio equipment 
audio equipment 
audio eauipment 
MCD 

audio equipment 

MCU 

MCU 

audio equipment 

audio equipment 
audio equipment 
MCU 



2,3 Data send/receive 

V24/V28 applies. 

Data is formatted in accordance with "terminal with 
small display". 

4 Ext ernal call indication on/off 

When pin 4 is activated, MCU toggles the external 
' call indication on/off. When oh, the external call 
indicator (e.g. horn) is activated when a message is 
received. 
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pins: 

5,6 Volume up/down . 

Grounding pin 5 or 6 will adjust the audio level- 
(volume) of the loudspeaker or the earphone, 
whichever is active when the pin is activated. (The 
audio level of the inactive unit will remain as 
before.) The adjustment is made in steps, one step 
for each new activation of the pin. If the pin is 
activated continuously, the level to be adjusted by 
one step per second. The lowest level possible to 
set muse still be noticeable. 

8 System start 

MCU will' start up within 10 seconds when pin 8 is 
activated, it then remains on until switched off by 
other means even if the pin is inactivated. 

9,10 Power supply of connected equipment 

+12V (pin 9) is able of supply a current of at least 
500 mA and -12V (pin 10) a current of at least 100 

mA. - •.' 

11,12 Microphone input 

Input impedance: 10 kohm. 

Sensitivity: .An input signal with the frequency 
1 kHz and a level of 100 mV produces an RF deviation 
of 3.0 kHz. This level is produced by the microphone 
at a sound pressure of 94 dB above 2*10~ pascal. 

13 Microphone hook on/off 

When the microphone or handset is lifted from its 
holder, pin 13 is activated (HOOK_OFF signal 
generated). If a handset with earphone is used, the 
loudspeaker will be inactivated and the earphone 
activated. When the microphone or handset is placed 
in its holder again, pin 13 will be inactiveted 
(HOOK_ON signal generated). If an earphone has been 
used, it will be inactivated and the loudspeaker 
activated (for audio level settings, see pin 5,6). 

14 Transmit/receive switch 

When activated, the radio unit will transmit and 
when deactivated, the radio unit will receive (push- 
to-talk switch). 

1,15 Earphone/loudspeak e r 

This output is able to support impedances down to 4 

Earphone sensitivity: The earphone produces a sound 
' pressure of 85-95 dB above 2*10~ pascal when driven 
by a signal with the frequency 1 kHz and a level 
corresponding to an RF deviation of 3.0 kHz. 



Exhibit 2, p. 740 



Cantel Mobitex 



1056 - A 296 5175/3 Ue 

te.aa nrE — 

1990-02-23 A MTS19 



5.1 PHYSICAL INTERFACE 

The terminal interface uses a 15-pole DSOB socket (female 
socket with pins) with the following configuration: 



PIN 


SIGNAL 


ACTIVE 


SOURCE 


1 


emergency 1 


emerg=0V 


emergency 


equip. 


2 


emergency ACK 


ACK =0V. 


Men 




3 


eraergency_ack. from fixed 


emack=0V 


MCU 




4 

5 


emergency~ack. ACK 


ACK =0V 


emergency 


equip. 


6 


emergency 2 


emerg=0V 


emergency 


equip. 


7 


ground for control signal 








8 


system start 


start=0V 


emergency 


equip. 


9 


+12V (supply) 




MCU 




10 


* 








11 


emergency 3 


emerg=0V 


"emergency 


equip . 


12 


emergency 4 


emerg=0V . 


emergency 


equip. 


13 


emergency LP input 




emergency 


equip. 


14 


emergency LP ground. 




emergency 


equip. 


15 


external indicator 


on = 0V 


MCU 





* = reserved 



pins: 

1 . Emergency 1 

Emergency alarm from an external emergency unit, 
e.g. a receiver for emergencies sent on radio from a 
pocket transmitter. Emergency 1 (pin 1) is used 
together with pin 8 (system start) and pin 2 
(emergency ACK from MCU) to be able to initiate an 
emergency alarm even if MCU is powered off. When the 
external emergency unit* initiates the alarm, it 
activates both pin 1 (emergency 1) and pin 8 (system 
start). After detecting the. alarm, MCU sends an 
acknowledge to the emergency unit by activating pin 
2 (emergency ACK from MCU). The emergency unit must 
keep pins 1 and 8 activated until this ACK has been 
received. 

MCU will then create and send a SOS packet to the 
network. 



2 Emergency ACK from MCU 

Emergency ACK is an acknowledgement from MCU that 
emergency 1 has been received by MCU (response to 
- activation of pin 1). 
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Emergency acknowledgement from fixed terminal 
When the fixed terminal has received the emergency 
message (SOSINFO), it can send a special emergency 
acknowledge packet (SOSACK) or a request for an 
emergency connection (SOSCONREQ) addressed to the' 
alarming" subscription. When a SOSACK is received by 
MCD, it indicates this to the emergency unit by 
grounding pin 3. The emergency unit in turn grounds 
pin 4 as an acknowledgement. 

Additional reactions from MCO when receiving SOSACK 
or SOSCONREQ are very much depending on application. 
A parameter emergency-acknowledge-status should be 
implemented and stating at least the following: 
status = 0 no additional reaction 

1 activate external indication (e.g. horn) 

2 emergency line connection in direction 
mobile to base (one-way, mobile 
transmitting) 

3 send acknowledge to op. terminal 

Emergency acknowledgement ACK from emergency i 
Used by the emergency unit to acknowledge the 
activation from MCO of pin 3. 

Emergency 2, 3 and 4 

These pins are intended for initiating an emergency 
alarm from simple emergency equipment such as a 
single push button. When one of these pins is 
.activated, MC0 creates a SOS packet and sends it to 
the network. Should the pin remain active, the time 
between repeated SOS packets must be at least 1 
minute. The signals are not acknowledged by MCU. 

System start 

MCO will start up within 10 seconds when pin 8 is 
activated. It then' remains on until switched off by 
other means even if the pin is inactivated. 

Power supply for external equipment 

+12V is able to supply a current of at least 500 raA. 

(The emergency unit should always be powered up) 

Emergency LF input- (for emergency connection) 
Input impedance: 10 kohra. 

Sensitivity: An input signal with the frequency 
1 kHz and a level of 100 mV produces an RP deviation 
of 3.0 kHz. This level is produced by the microphone 
at a sound pressure of 94 dB above 2*10 pascal. 

- Activation of external indicator 
This pin is used to activate an external indicator 
(e.g. horn). It is able to sink at least- 100 mA to 
operate e.g. a relay which activates the horn (open 
collector output) . 
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5.2 Time diagram; 
EMERGENCY UNIT (emergency 1); 



packet 


radio path 


RADIO/HCU 


interface 


em. unit 


SOS 




.start 
emergency 1 
emergency ACK 
send emergency signal 
(external indicator 
might be activated 


< 8 

< l 

2 > 

15 > 


start up 
emerg. 1 
ack 

horn) 



IN CASE OP MANUAL ACKNOWLEDGE FROM FIXED TERMINAL AFTER 
RECEIVING SOS INFO 



emerg. _ack from fixed 



acc. to em. ack. status 
(•e.g. ext. indicator 



fixd ack 
"ack 



EMERGENCY BUTTON (emergency 2, 3 or 4): 



packet 


radio path 


RADIO/MCO 


interface 


em. butt. 


SOS . 


< 


emergency 2 (3 or 4) 
send emergency signal 
(external indicator 
might be activated 


< 6 

15 > 


emerg. 2 
horn) 



IN CASE OF MANUAL ACKNOWLEDGE FROM FIXED TERMINAL AFTER 
RECEIVING SOSINFO 



emerg. _ack from fixed 



acc. to em. ack. status 
(e.g. ext. indicator 



3 / 

15 > 
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6 APPLICATION EXAMPLES 

The interfaces can be used in a variety of ways depending on 
the application. Below are some examples given. 

The terminal equipment can be connected to these interfaces. 

OP. TERMINAL 



terminal interface 
plug 



The op. terminal comprises a 
display for- message presen- 
tation and editing and a 
keyboard for entering com- 
mands and information. 



printer interface 
plug 



Printer for printing out 
text or data collection 
unit sending text strings. 



audio interface 
plug 



15pin 



AUDIO EQUIPMENT 



Loudspeaker and microphone 
or handset with or without 
keys-. 

Switches/buttons to control 
interface signals and/or 
serial data according to 
V24/V28. 



emergency interface 
plug 



15pin 



EMERGENCY EQUIPMENT 



Emergency unit, e.g. receiver 
for emergencies from pocket 
transmitter, or simple 
emergency buttons to initiate 
emergency signal (SOS) from 
MCO. 
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The following examples are described: 

1. Microphone/loudspeaker 

2. Handset with numeric and function keys 

3. Handset with numeric and function keys, printer 

4. Microphone/loudspeaker, control unit, printer . 

5. Op. terminal with small display, loudspeaker, printer 

6. Op. terminal of ANSI type, microphone/loudspeaker, data 

collection unit 

7. PC, microphone/loudspeaker 

8. PC, handset with keys, printer, emergency equipment 

9. PC, microphone/loudspeaker, control unit, printer, 

emergency equipment 

(PTT = push-to-talk button) 



1. Microphone/loudspeaker 



A=audio interface 



Is able to send/receive speech. (Sends only to default 
receiver) 



2. Handset with numeric and function keys 



i 

■a 



H=earphone 

A=audio interface 
M=microphone 



Is able to" send/receive status and speech. 
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3. Handset with numeric and function keys, printer 



3 



H= earphone 

A=audio interface 
M=micro'phone 



1 PRINTER | TP=term. inter f. 

printer 

Is able to send/receive status and speech and to receive text. 
4. Microphone/loudspeaker, control unit, printer 



IPTT 



LOUDSP 

~~T 



A=audio interface 

TP=term. interf. 
printer 



Is able to send/receive status and speech and to receive text. 
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5. Op. terminal with small display, microphone/loudspeaker, 
printer 



A=audio interface 



-| OP-T ERMINAL | TD=term . inter f. 
L — small display 



PRINTER | TP=term. interf. 
printer 



Is able to send/receive text, status and speech. 



6. Op. terminal of ANSI type, microphone/loudspeaker, data 
collection unit. 



MIC -1PTT LOODSP 



A=audio interface 



1 DATA COLL. | TP=term. interf. 

printer 

Is able to send/receive text, data, status and speech. Data can 
be controlled and collected over radio in the form of text 
strings to and from the data collection unit. 
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7. Personal computer as terminal, microphone/loudspeaker 



A=audio interface 



Is able to send/receive text, data, status and speech. 



8. Personal computer as terminal, handset with numeric and 
function keys, printer, emergency equipment 



A=audio interface 



TH=term. interf. 
'raasc' 



. PRINTER I TP=term. interf. 
printer 



"I EHERG . EM=emergency interf 



Is able to send/receive text,, data, status, speech and 
emergency. 
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9. Per sonal computer as terminal, microphone/loudspeaker, 
control unit, printer, emergency equipment ~ 



A=audio inter f. 



TP=term. interf. 
printer 



EMERGENCY | EM=emerg. interf r 



Is able to send/receive text, data, status, speech and 
emergency. 
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7 MOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 

Rl-06, 4 
Rl-09, 16 



Below are the reference designations listed. 



Reference Section 

Rl-01 .. Arrangement of the documents 

Rl-02 MOBITEX System description 

Rl-03 General description of terminals 

Rl-04 Terminology 

Rl-05 References 

Rl-06 Network operator information 

Rl-08 Application layer 

Rl-09 Network layer 

Rl-11 interface requirements, fixed terminals 

Rl-12 Other requirements, fixed terminals 

Rl-16 Link layer, mobile terminals 

Rl-17 Physical layer, mobile terminals 

Rl-18 Radio equipment, mobile terminals 

Ri-19 Other interfaces, mobile terminals 

Rl-20 Other requirements, mobile terminals 
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Cantel Mobitex- 


MOBITEX Terminal Specification 
Mobitex ASyncronous Communication 
APPENDIX A, Commands 



This. document specifies. commands in the interface MOBITEX 
ASyncronous Communication (MASC) used between an 
application and a mobile terminal. 
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1 INFORMATION FRAME COMMANDS AND FUNCTIONS IN MOBILE TERMINAL ■ 

The commands, questions arid replies available as information 
frames in MASC are summarized below and a description is given 
on the following pages. 

1.1 BASIC FUNCTIONS 

The following commands are always to be implemented in MCU. 

3 parameters for the MASC protocol 

M send/receive MPAK via radio 

E error command or function 

N return of MPAK that has not been sent 

R return of incorrect MPAK 

D route received MPAKs to an output 

S send MPAK to the specified output 

T request or transfer of emergency text 

D send emergency signal (SOS-packet) 

F p terminal subscription MAN request and answer 

F Q device handling the MASC protocol 

F F MCU in contact with Mobitex network 

F G MCU has no contact with Mobitex network 

F H MCU inform that MPAK has been sent over the radio 

F K Error message from MCU 

F 0 Prepare to close down MCU 

F # Short number list request and answer 



Exhibit 2, p. 755 



Cantel Mobitex- 



2/1056 - A 296 5175/2 Ue 
1990-02-26 <3 A |MTS19i 



1.2 TYPE TEST FUNCTIONS 

The following commands are always to be implemented in MCU. 

These functions should only be used during type testing and must 
be made inoperative for normal use. 

All requested parameters which are available in the mobile 
should be included in all answers to type test functions. 

Type test functions consist of commands belonging to specific 
radio protocol. 

To separate mobile terminals with different radio protocol, the 
following commands are available: 

P-command Used in mobile terminal at 1200bps. 

K-command Used in mobile terminal at 1200bps. 

PA-command Used in mobile terminal at 8/16kbps. 

KA-command Used in mobile terminal at 8/16bps. 
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1.3 TERMINAL SYSTEM FUNCTIONS 






The following commands to be implemented in MCU, according 
application. 


to 


F system control 




1.4 AUDIO FUNCTIONS 






The following commands to be implemented in MCU, according 
application. 




A controlling audio functions 




1.5 MANUAL RADIO FUNCTIONS 






The following commands to be implemented in MCU, according 
application. 


to 


H controlling .manual radio mode 




1.6 USER COMMANDS 






The following commands are free 
If used in application, contact 
implementation in MCU. 


to use in applications. - 
mobile raanufactor about 




X 

z 
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2 BASIC FUNCTIONS (always to be implemented in KCU) 

2 >1 B-command (parameters for the MASC protocol) 
Structure of text field: 



B I' SP | len 



II 3 11-4 
The data field is empty. 

The B-command is used to set parameters for the protocol. 

len is a 3-digit ASCII coded hex number which sets the maximum 
length of an Information frame. This field should always be set 
to the maximum possible frame size, i.e. 47E (1150 decimal). 

int is a maximum 4-digit ASCII coded hex number which sets the 
shortest time between two subsequent frames. The value is given 
m 10 ms increments. Default value is int = 0. 

len and int are separated by a , (comma). 

These parameters should be used as soon as they have been 
received. 

The default values are used until a B-command has been received. 
A B-command should be the first frame sent after start up. 

After receiving a B-command, the protocol should send a 
sfcart _ of _ lin e signal to a higher protocol, to make clear that 
the connection is established and that the start sequence can 
follow. 

Start_of_line signal is an internal signal between the link 
layer and higher layer. 
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2.2 M-command (send/receive MPAK via radio) 
Structure of text field: 



sequ-id j 



SP indicate that a sequence number identity is added. If no SP 
then there is no sequ-id. 

sequ-id is a 1-digit ASCII coded decimal number between 0-9. 
This sequence number is an identity of the MPAK. 

Structure of data fields 



MPAK _ 
16-1120 



MCU receiving the M-command sends MPAK via the radio path to the 
network. If M-command consists of a sequence number, the command 
FH indicating 'sent to mobitex network' is sent to terminal 
including the sequence number. Returned MPAK should also 
indicate sequence number. 

' MPAK received via the radio path, is sent over the interface to 
the terminal with the M-command (MAN is included in MPAK) . The 
sequence number is not used in this M-command. ' 



The received MPAK ( to be sent via the radio path) should be a 
permitted MPAK concerning valid information in the MPAK head and 
MPAK length (sender, traf state, class, packet type, size of 
MPAK) . 

Description of the different MPAKs can be found in " Network 
layer for terminals", see reference Rl-09. 
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2.3 S-command (Error command or function) 
Structure of text field: 



The datafield may be used to send information about =he error. 

The E-conudand informs that the previously received command or 
function cannot be executed. (Command or function is noc 
implemented in the receiving unit or included parameters are not 
accepted) . 
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2.4 N-command (return of MPAK 


not sent) ' 


Structure of text field: 


| N j SP j err-code j , | secu- 





SP indicate that an error code and sequence number are added. If 
no SP then there is no error code or sequence number. 

err-code is a 2-digit ASCII coded hex number between 00 - FF. 
This error code is described in chapter "Fault situation in 
raobitex mobile stations". 

sequ-id is a 1-digit ASCII coded decimal number between 0-9. 
This sequence number is an identity of the MPAK. 

Structure of data field: 



MPAK _ 
16-1120 



The N-command indicates- to the terminal that the MPAK has not 
been sent over radio (communication failure or transmission 
interrupted by FO or Fl-command). 

In manual mode MPAK's should be returned by the N-command. 

The MCO can indicate the reason, of not sending the MPAK over 
the radio/ by adding the error code. 

If a sequence number is indicated in the M-command, then this 
sequence number should also be in the N-frame. 

If no error code or sequence number is valid,, this pararameter 
is not added. 



Description of the different MPAKs can be found in " Network 
layer for terminals", see reference Rl-09. 
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2.5 fr-command (return of incorrect MPAK) 

When receiving the R-frarae and not finding the fault, the 
receiving unit is supposed to make a restart by sending a B- 
frame. 

Structure of text field: 



j 5 I SP | err-code j , } sequ-id""] 

112 11 
SP indicate that an error code and sequence number are added. If 
no SP then there is no error code or sequence number. 

err-code is a 2-digit ASCII coded hex number between 00 - FF. 
This error code is described in chapter "Fault situation in 
mobitex mobile stations". 

sequ-id is a 1-digit ASCII coded decimal number between 0-9. 
This sequence number is an identity of the MPAK. 



Structure of data field: 



MPAK 
16-1120 



MCD uses the R-frame to return an MPAK which was received with 
the M-command and which does not comply with the format and the 
rules set by the network and link layers of MOBITEX terminals. 

The MCD can indicate the reason, of not accepting the MPAK, by 
adding the error code. 

If a sequence number is indicated in the M-command, then this 
sequence number should also be in the N-frame. 

If no error code or sequence number is valid, this pararameter 
is not added. 



Description of the different MPAKs can be found in " Network 
layer for terminals", see reference Rl-09. 
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2.6 D-command (route received MPAKs to an output) 



Structure of text field: 



| D j SP j MAN j , j 3TG j , { TYP j , j SET [ 
1 1.6 111111 



The data field is empty. 

MAN is a 6-digit ASCII coded hex number stating the MAN for 
which MPAKs are to be routed to output OTG.MAN must be one of 
the possible MANs of the terminal (terminal MAN, group MAM or 
personal MAN} . 

CJTG is a 1-digit ASCII-coded hex-number stating the output to 
which received MPAKs are to be routed. 

TYP is a 1-digit ASCII-coded hex-number stating the type of MPAK 
which is to be routed to OTG ._. 



SET is activating the function of set/reset these parameters. 
UTG and TYP to be used as follows: 



default output 
printer 
audio 
emergency 

op. terminal :1 (MASC protocol) 

op. terminal: 2 

op. terminal: 3 

op. terminal: 4 

op. terminal: 5 

op. terminal: 6 

no types (reset all) . 

text 

data 

status 

line connection (speech) 
emergency • 

all types except emergency 

extpak 

hpdata 

dteserv 



set these parameters 
■ reset these parameters . 
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After receiving the D-command, MCU will route incoming MPAKs of 
the specified type and intended for the specified MAN to the 
function block which handles the communication (formatting etc) 
for the specified output.. Thus it is possible to route MPAKs to 
several outputs e.g. to both printer and op. terminal. 

When receiving a D-command with UTG="default output", 'the MCU 
resets all earlier D-commands for the SDecified MAN and 
specified TYP. If for example the TYP is "all types", all 
earlier 0-commands concerning this specified MAN are reset and 
all types are sent to default output" connection. If TYP is "no 
types", then all types is reset for this MAN and OTG. 

It is possible to set or reset an earlier D-command, using the 
parameter set or reset. 

After logout, a personal subscription should be removed from 
this list of routing. MPAKs. 

When power on, MCD sets up default outputs, e.g. text, data and 
status.-to op. terminal- and line connection to audio interface. 

All MPAK : DTESERV is routed to output, where terminal MAN is 
located(can be more than one). 

Description of the different MPAKs can be found in " Network 
layer for terminals", see reference Rl-09. 
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2.7 S-command (sends MPAK to the specified output) 
Structure of text field: 



Structure of data field: 
MPAK _ 2| 



16-1120 

DTG is a 1-digit ASCII-coded hex-number which states to which 
output MPAK is to be -sent. 

When receiving the S-conunand, MCU sends MPAK to the output 
s ta ted Jay QTG. ■ 

The parameter DTG is to be used as follows: 

DTG = 0 direct to default output 

1 printer 

2 audio 

3 emergency 

4 op. terminal :1 (HASC protocol) 

5 op. terminal: 2 

6 op. terminal: 3 

7 op. terminal: 4 

8 op. terminal: 5 

9 op. terminal: 6 



P printer, without printing the MPAK-head 

Note 1: When the parameter UTG = F, the datafield consists of 

printable information except the MPAK-head. The printer 
should ignore the MPAK-head, this means that the 
information starts in octet 12. 

Description of the different MPAKs can be found in " Network 
layer for terminals", see reference Rl-09. 
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2.8 T-command (request/transfer of emergency text). 
Structure of text field, request: 

m 

i 

Structure of data field for transfer of emergency rext: 



Emergency text 
0 - 2S6 



The T-command is used by the terminal to set up in MCO the 
dynamic text part of the emergency signal and as a request to. 
MCO to return the stored emergency text. MCU uses the command as 
a reply to the request. 

The emergency text field is the emergency text which is to be 
transferred. The emergency text can have up to 256 characters 
according to MOBITEX textcode. The first two octets of the text 
part are reserved to indicate the source of the emergency. 

Source of emergency: Emergency 1 = 01 
Emergency 2 = 02 
Emergency 3 = 03 
Emergency 4 = 04 
Handset = 05 

OP-terminal 1 = 06 



When receiving a T-command with text part, MCU stores emergency 
text as the dynamic text part of a possible, future SOS packet. 
When receiving the T-command request, the stored emergency text 
is sent to the terminal, by the . T-command with text part. 

Description of the emergency packets and procedures (SOS, 
SOSINFO etc) can be found in "Network layer for terminals" , see 
reference Rl-09. 
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2.9 O-command (send emergency signal SOS) 



The O-command is used by the terminal to initiate the 
transmission of an emergency signal (SOS packet). 

When receiving the O-command, HCD creates a SOS packet and sends 
it to the network. The text part of SOS is made up by the stored 
emergency text (received earlier by the T-command) where the 
identity of the emergency source is inserted as the first two 
octets. 

Description of the emergency packets and procedures (SOS, 
SOSINPO etc) can be. found in "Network layer for terminals", see 
reference Rl-09. 

When MCO is in manual mode, it is recommended that the MOT • 
return to MOBITEX" operating~mode and sends tha packet MPAK:SOS. 
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2. 10 F P-command (MAN request) 




The FP-coramand is described in 


chapter TERMINAL SYSTEM FUNCTIONS 


F-command. 


2.11 F Q-command (device handlinq the MASC orotocol) 


The FQ-command is described in chapter TERMINAL SYSTEM FUNCTIONS 


F-command. 




2.12 F F-command (MCU in contact with mobitex) 


The FF-comraand is described in 
F-command . 


Chapter TERMINAL SYSTEM FUNCTIONS 


2.13 F G-command (MCU not in contact with mobitex) 


The FG-command is described in chapter TERMINAL SYSTEM FUNCTIONS 


F-command. 




2.14 F H-command. (MPAK sent .over -radio path) 


The FH-command is described in 


chapter TERMINAL SYSTEM FUNCTIONS 


F-command. 


2.15 F K-command (error message from MCU) 


The FK-comraand is described in chapter TERMINAL SYSTEM FUNCTIONS 


F-command. 




2.16 F o-command (prepare to close down) 


The FO-command is described in 


chapter TERMINAL SYSTEM FUNCTIONS 


F-command . 


2.17 F #-coramand (short number 


list) 


The F#-command is described in chapter TERMINAL SYSTEM FUNCTIONS 


F-command . 
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3 TYPE TEST FUNCTIONS (always bo be implemented in MCD) 

These functions should only be used during type testing and must 
be made inoperative for normal use. 



3.1 ?-command (request/list of parameters) 

Structure of text field in request for internal parameters from 
terminal to MCD: 



1 

Structure of text field in reply from MCD to terminal (list of 
parameters ) : 



iris"t-"of -parameters 



(internal parameters in MCD) 
(internal parameters in MCD) 



No of bytes 



The data field is empty. 

The P-command is used by the terminal to request radio protocol 
parameters and by MCD to send these parameters as a reply to the 
request. 

The list of parameters consists of a number of ASCII coded hex 
numbers separated by , (comma). The parameters to be sent in the 
following order: 

Parameter 

Slot_length 
Timeout_short 
Timeout_long 
Free_slots 
Rand_slots 
Current_base 
Chosen_slot 
Max_access 
Max rep 

Priority (internal parameter in MCD) 
Sequential number up (term. MAN) 
Sequential numbers down (term.MAN+15 groups) 
Dpfreq (current) 
Dofreq (current) 
Flexlist (MAN 1-7) 
Grouplist (MAN 1-15) 



The meaning and structure of the different parameters can be 
found in "Data link layer for terminals", see reference Rl-16. 
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3-2 PA-comraand (request/list of radio-parameters) 



Structure of text field in request for internal parameters from 



Structure of text field in reply from MCO to terminal (list of 
parameters): 



[ PAOl | SP Jj-ist of_parameters] 

4 1 >=23 
The data field is empty. 

The PA-command is used by the terminal to- request ..radio protocol 
parameters and by MCO to send these parameters as a reply to the 
request. 

The list of parameters consists of a number of ASCII coded hex 
numbers separated by , (comma). If a parameter is not available 
or not given, this parameter is not included. The parameters to 
be sent in the following order: 

Parameter 



No of bytes 



Timeout 
Slot length 
Free~slots 
Rand~slots 
Max_rep 
Max~access 
Max~speech 
Txpow 
Slevl 
Slev2 
Scan time 
BadJEase 
Goodjbase 
Choose_base 
Better_base 
Qpos 

Chosen_slot . (internal parameter in MCO) 
Priority (internal parameter in MCO, current value) 
Opfreq (current value) 
Dofreq (current value) 
•Access_channel_upfreq (current value) 
Access~channel dofreq (current value) 
Network id (mobile tx) 
Network~id (mobile rx) 
Area id - 



(internal parameter in MCO) 
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PA01 01,02,03,04,05,06,07, 

18, 19, 0020, 0021/0022, 0023, 0024, 0025, 26 



TERMINAL 
PA01 

, 09, 10, 11, 12, 13, 14, 15, 16, 0017, 



PA01 01,02,03,04,,,,,,,,,,,,,,,,, ,,,,,26 

The meaning and structure of the different parameters can be 
found in "Data link layer for terminals", see reference Hl-16. 
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3 « 3 PA-command (request/list of identity-parameters) 

Structure of text field in request for identity parameters from 
terminal to MCU: 



Structure of text field in reply from MCO to terminal (lisc of 
parameters ) : 



I 1 SP ]jList of parameters] 

4 1 >=40 
The data field is empty. 

The P-*eommand -is used by the terminal to request radio pr-o-tocol 
parameters and by MCU to send these parameters as a reply to the 
request. . 

The list of parameters consists of a number of ASCII coded hex 
numbers separated by , (comma). If a parameter is not available 
or not given, this parameter is not included. The parameters- to 
be sent in the following order: 

Parameter 

Terminal MAN 
ESN 

Flexlist (MAN 0-7) 
Grouplist (MAN 1-15) 
Sequential number up (term. MAN) 
Sequential numbers down (term.MAN+15 groups) 



No of bytes 



Example of PA02-command: 

MCD TERMINAL 

< PA02 

PA01 000001,00000002,000003,000004,000005, 
26,27,,, ,,,,,,42 



The meaning and structure of the different parameters can be 
found in "Data link layer for terminals", see reference Rl-16. 
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3.4 PA-command (request/list of channel-parameters) 



Structure of text field in request for parameters from terminal 



Structure of text field in reply from MCtl to terminal (list of 
parameters): 



of parameter^ 



4 1 >=4 
The data field is empty. 

The P-command -is -used by -fefee terminal to -request- radio protocol 
parameters and by MCO to send these parameters as a reply to the 
request. 

The list of parameters consists of a number of ASCII coded hex 
numbers separated by , (comma). If a parameter is not available 
or not given, this parameter is not included. The parameters to 
be sent in the following order: 

Parameter No of bytes 

Channel_list (current) 1 

Number_of_channels in channel_list (total) 2 

Number of_channels in this command 1 

Channel #1 - upfreq 2 

Channel #1 - dofreq 2 

Channel #2 - upfreq 2 

Channel #2 - dofreq 2 



Channel-list = Ol(hex) DEFAOT,T_LIST 

02 (hex) ' CURRENT_LIST 
03 (hex) T£MP_DEFAUI»T_L 1ST 

All parameters in this command is a number of ASCII coded hex 
number . 

Example: Answer with a default list of 100 channels. 

PA03 01, 0064, 3C r 0123, 0123, 

PA03 01,0064,28,0123,0123, 



The meaning and structure of the different parameters can be ■ 
found in "Data link layer for terminals", see reference Rl-16. 
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3.5 PA-command (reauest/list of roamina-parameters) 




to^co" 6 ° f t6Xt fi6ld in request for Parameters from terminal 




1 PA05 | 
4 " 






parameters?- ^ f " ld ln rSply fr ° m MCa t0 cecininal ("at of 




| PA05 | SP £jList of parameters] 




4 1 >=4 






The data field is empty. 






- - - The ; -P-.G<3iffinafid-is-used by the terminal to request radio -protocol - — 
Posters and by MCO to send these parameters as a reply to the 




The list of parameters consishs 
numbers separated by , (comma), 
or not given, this parameter is 
be sent in the following order: 


of a number of ASCII coded hex 
If a parameter is not available 
not included. The parameters to 




Parameter 


No of bvtes 




Number of bases in table 

Current_base_id 

r oami ng~va 1 u i* 

Base_id 

roaming_value 


1 
2 
1 
2 

• 1 




Example: Mobile terminal with current_base(23) choosen. 




PA05 03,0023,09,0025,02,0019, 


04 




Mobile terminal with no choosen current_base . 




PA05 03,,, 0023,02, 0019, 01 






The meaning and structure of the different parameters can be 
round in "Data link layer for terminals", see reference Rl-16. 
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3-6 PA-command ( request/list' of test-parameters) 



PA06 SP function 



iter I 



Structure of text field in reply from MCU to terminal (list < 
parameters): 



PA05 SP function 



I list of parameters 



The data field is empty. 

- The. P-command is used by . the- terminal to reque_s_t..foE. radio 
protocol parameters and* by MCU to send these parameters as a 
reply to the request. 

The function -is a ASCII coded decimal number between 00'- 99, 
describing separate request or answer. Those functions are 
described below. 

Tne list of .parameters consists of a number of ASCII coded hex 
numbers separated by , (comma). If a parameter is not available 
or not given, this parameter is not included. The parameters to 
be sent in. the following order: 

Function: 



No: description: 

01 current_base(Req/ans) 

02 set current_base 

03 disable base_search_mode 

04 enable base searchjnode 

05 clear dynamic memory 

06 enable copy REPMAP when 
receiving or sending the 
frame <REB> 



07 disable copy REPMAP 

08 enable loudspeaker 

09 disable loudspeaker 



parameter: 

In the answer, the current_base 
is in ASCII coded hex number. 
Current_base in ASCII coded hex 
number . 



An ASCII coded hex number for 
each bit set to "1" indicating 
repetition in the frame <REB>. A 
comma is placed between each 
number. 
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description: 
copy NOMRET 



parameter; 

The parameter NOMRET in ASCII 
coded hex number, stating the 
number of retransmissions, 
enable transmitting the 
scrambling signal over 
the radio (see ref Rl-17 ) - 
disable transmitting the 
scrambling signal over 
the radio(see ref Rl-17 ) - 

copy speech parameters. Subscriber, con-id, upfreq, 
dofreq. Parameters in" ASCII 
coded hex number separated by a 



Example: MOT . Terminal 

< PA6 01 

-PA6- 01,1234— — >-*.. _.. - 

<--' PA6 02,1234 

< PA6 06 

PA6 06,6,23,35 ---> 

< PA6 07 

< PA6 08 

< ~ PA6 09 

< PA6 10 

PA6 10,12 > 

< PA6 12 

< PA6 11 

< PA6 13 

PA6 13,123456,12,1111,2222 > 

The meaning and structure of the different parameters can be 
found in "Data link layer for terminals", see reference Rl-16. 
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3 « 7 K-command (receive/transmit frequency number) 
Structure of text field to frequency number reception! 



| KM | SP I parameter 



Structure of text field to frequency number, transmissi 



The data field is empty in both commands. 

The parameter f i-el-d-states the frequency number. The number is 
given as the ASCII codes of the hexadecimal digits of the 
frequency number in hexadecimal notation. 

The K-command is used to set up the frequency pair to be used 
for reception and transmission. The frequency number range is 
hexadecimal 001 - S17 (decimal 0001 - 1559). 

If the frequency number included in the frame is not implemented 
in the equipment, MOT will respond with an E-frame (error 
function). 

For correspondence between frequency number and frequency, see 
reference Rl-06 . 
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3.8 KA-command (receive/transmit frequency number) 
Structure of text field to frequency band: 



Structure of text field to frequency number . reception: 



KAM I SP | parameter 



Structure of text field to frequency number transmission: 



KAS I SP I parameter 



The data field is empty in all commands. 

The parameter FBI states the frequency band and bitrate. The 
parameter is given as the ASCII coded hex number of the 
parameter FBI in upfreq and dofreq. 

The parameter field states the frequency number. The number is 
given as the ASCII codes, of the hexadecimal digits of the 
frequency number in hexadecimal natation. 

The KA-:coraraand is used to set up the frequency pair to be used 
for reception and transmission. The frequency number range is 
hexadecimal 0001 - 1FFF (decimal 0001 - 8191). 

If the frequency number included in the frame is not implemented 
in the equipment, MCD will respond with an E-frame (error 
function) . 

For correspondence between frequency number and frequency, and 
frequency band(FBI) and bitrate , see reference Rl-06. 
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4 TERMINAL SYSTEM FUNCTIONS (implemented according to 
application) 

4.0 F-command (system control) 

The F-command is used from op. terminal to execute the soecified 
function in MCU. 

The F-coramand is used by MCU to send information to the 
terminal. 

Structure of the text field: 



F | SP | list of parameters 



The data field is used only in the FT- and F#-frame with list of 
channel numbers and short numbers. 

- The list . of parameters is a . list of one-character function codes 
and parameters in ASCII code according "to the following table: 

4.1 F B Change to MOHITEX operation mode 

MCU sends an ACTIVE packet to the network 

4.2 F C Set up a MOBITEX line connection 

parameters MAN1,MAN2 

MAN is a 6-digit ASCII-coded hex-number. 

MANl=sender, MAN2=addressee. 

MCU creates and sends a CONREQ packet to the 

network. 

4.3 F D Set up a TELEPHONE line connection 

Parameters MAN, TEL 

MAN is a 6-digit ASCII-coded hex-number (sender). 
TEL is the desired number in the telephone network. 
The number is given in MOBITEX textcode, right 
justified in a 20 character field with leading 
spaces according to the corresponding field of 
EXTCONREQ. 

MCU creates and sends an EXTCONREQ packet to the 
network. 

4.4 F E Disconnect line connection 

MCU creates and sends a DISCON packet to the 
network . 

4.5 F F Contact with the MOBITEX network 

"MCU is in contact with the MOBITEX network. 

4.6 'FG No contact with MOBITEX network 

MCU has no contact with the MOBITEX network and is 
trying to establish contact again (roaming procedure 
started) . 
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MPAK sent by the radio to the network 
Parameter SEQU-ID 

MCU inform that MPAK has been sent to the network. 
The parameter SEQO-ID is added if SEQU-ID was 
included in the M-comtnand. SEQO-ID is a 1-digit 
ASCII coded decimal number, between 0-9. 

Cancell previously transmission of MPAK 
Previously activated transmission of MPAK is 
cancelled. The MPAK zo be returned zo rhe terminal 
by an N-f rame. 

Print out current MANs in terminal 
Print current MANs in terminal on printer (terminal 
subscription MAN, group MANs (group list) and 
personal subscription MANs (flex list) in that 
order. — 

Error message about a fault situation 
Parameter XX 

r- Erxor message where XX is the error -number in^-ASCII 
coded hex digits 00-FF (0-255). 
Information from MOT about a fault situation. 
Description of the meaning fault situation see 
chapter "Fault situation in mobitex mobile 
stations". 

Activate external call indication 

Activate external indication (e.g. horn) for 2 

seconds . 

Transmitter on/off 
Parameter X 

X = character 0 > transmitter off 

X = character 1 > transmitter on 

Change to MANUAL RADIO mode 

MCU sends an INACTIVE packet to the network. 

Prepare for closing down MCU 

From terminal: Command to prepare closing down 

(switching off) the MCU. 

MCU clears buffers for stored MPAKs. MPAKs to be 
transmitted to the network are transmitted. All 
other MPAKs are sent to the terminal. If no contact 
with the network, MPAK's to the network are returned 
by the N-command. 

Then MCU sends an INACTIVE packet to the network. 
Finally MCU confirms that it is empty by sending a 
' FO-frame to the terminal. 
From MCU: MCU is empty and ready to be switched off. 

Note: If more than one device connected, the FO- 
command from the MCU should be sent to all 
devices. 
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Terminal MAN request/answer 

Request from terminal for terminal subscription MAN. 

:XXXX Terminal subscription MAN from MCU to 
terminal as response to the request. 
XXXXXX is the MAN as a 6 digit ASCII coded 
hex number. 



Parameter XXX 

Type of device handling the MASC protocol. 
F_Q(MASC_DEVICE) is information to other units 
connected to this MASC interface. 
XXX = MCO 
XXX = MOX 

4.17 PR Change network identification 

Parameters XXXX,YYYY 

Send this new network identification to data link 
layer(see reference Rl-16). 
.. , - r- JCXXX = is new -network_ID for mobile tx in ASCII 

coded hex number. 
YYYY = is new network_ID for mobile rx in ASCII 

coded hex number. 

4.18 F S Change AREA-LIST 

Parameters BITMAP , COM 

Send this new area list to data link layer (see 

reference Rl-09 and Rl-16). 

BITMAP = see AREALIST reference Rl-09. 

COM = see Command reference Rl-09. 

Parameters BITMAP and COM is in ASCII coded hex 

digits. 



4.19 FT Change TEMP_DEFAULT_L I ST 
Parameters TNDM,NUM,M 

Send this new channel list to data link layer (see 
reference Rl-09 and Rl-16) . 

TNOM = Total number of channels. If TNDM is zero, 
delete TEMP_DEFAOLT LIST and return to 
DEFA0LT_L 1ST. ~ 

NDM = Number of channels in this command 

M = 0 No more channels 

M =1 More channels in next command. 

Parameters TNDM, NUM and M is in ASCII coded hex 

digits. 

The list itself is sent in the data field of the 
frame. The list is described in reference Rl-16. 



Exhibit 2, p. 



Cantel Mohitex- 



1990-02-26 A 



4.20 P 7 Speech queue information 

Parameter XX 

Information about queue-position when waiting for 
speech to be connected. 

XX is the speech-queue number in ASCII coded hex 
digits in the range 00-FF. 

4.21 F I Short number list 

Request from terminal for short number list. 

F SXX List, of short numbers from MCtI or terminal. 

The list contains short, numbers whicrTare 
common to MCO and all connected terminals 
(general short numbers). It is sent by the 
terminal to set up this list and by MCO as a 
reply to the F# request frame from the 
terminal . 

•XX is the number of short numbers in the 
list in ASCII coded hex digits in the range 
00-32 (0-50 decimal). 

'• " The list itself-is sent in- the data field -of- - 

the frame. In the list, the actual numbers 
corresponding to each short number from 1 
and up are given as ASCII coded digits with 
a maximum of 20 digits each". The numbers are 
separated by the character , (comma). 

NOTE: Only the 'one-character function' can. be included in an F- 
command, e.g. F P123456. 

Description of the different packets and procedures mentioned 
here can be found in reference Rl-09 and Rl-16. 



I 
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5 AUDIO FUNCTIONS (implemented according to .application) 
5 . 0 A-command (controlling audio functions) - 
Structure of text field: 



list of parameters 



The data field is empty. 

The A-command is used to control the audio equipment. 

The list of parameters is a list of one-character function codes 
and parameters in ASCII code according to the following table: 

5.1 A B Increase audio volume level 

5.2 AC Decrease- audio. vaJLuma. level 

5.3 .AD Loudspeaker on/off 

Parameter X 

X = character 0 — > off 
X = character 1 — > on 

5.4 A E External call indication on/off 

Parameter X 

X = character 0 — > off 
X = character 1 — > on 

5.5 AH Microphone (hook) on/off 

Parameter X 

X = character 0 — > off 
X = character 1 — > on 

5.6 A I Transmit/receive switch 

Parameter X 

X = character 0 — > transmit 
X = character 1 — > receive 

5.7 A J Hands free. 

Parameter X 

X = character 0 — > off 
X = character 1 — > on 

5.8 A V Audio level order. 

Parameter X 
' X=data, ASCII coded hex digit 0-F. 

NOTE: Only the "one-character function' can be included in an A- 
command, e.g. A E0. 
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6 MANUAL RADIO MODE FUNCTIONS (implemented according to 
application) 

6.0 H-command (controlling manual radio mode) 
Structure of text field: 



H I SP I list of parameters 



The data field is empty. 

The H-command is used to control the radio equipment when in 
manual radio mode. 

The list of parameters field is a list of one-character function 
codes and parameters in ASCII code according to the following 
table: 

6.1 HA Change to MOB I TEX mode. 

MCU sends an ACTIVE packet to the network. 

6.2 H B Increase audio volume level. 

6.3 H C Decrease audio volume level. 

6.4 H D Loudspeaker on/off. 

Parameter X 

X = character 0 — > off. 
X = character 1 — > on. 

6.5 HE External call indication on/off. 

Parameter X 

X = character 0 — > off. 
X = character 1 — > on. 

6.6 H F Call indication 

Parameter X 

X = character 0 — > no call received 
X = character 1 — > call received 

6.7 H G Squelch open/closed (toggle). 

6.8 H H Microphone (hook) on/off. 

Parameter X 

X = character 0 — > off. 
X = character 1 — > on. 

6.9 HI Transmit/receive switch 

Parameter X 

X = character 0 — > transmit 
X = character 1 — > receive 



A.2B2SISM 
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Hands free. 
Parameter X 

X = character 0 — > transmit 
X = character. 1 — > receive 

Change to channel number. 
Parameter XX 

Change zo channel number XX where XX is the desired 
channel number in ASCII coded hex digits in the 
range 01-53 (1-99 decimal). 

Channel number indication. 
Parameter XX 

XX is the channel number in ASCII coded hex digits 
in the range 01-63 (1-99 decimal). Will be sent, whem 
start up or a changed channel occur. 

Send selective, call number. 
Parameter XXXXXXX 

Send selective call number XXXXXXX on current 
...channel. 

X is an ASCII coded digit 0-9. 

If the number of digits is less than 7, the number 
will be left justified and the XXXXXXX-f ield will be 
filled with trailing spaces (hex code 20). 

Scan the specified channels. 
Parameter XX.. XX 

XX.. XX is a list of maximum 8 channel numbers in a 
field of 16 octets. Each XX represents a channel 
number in ASCII coded hex digits in the range 01-63 
(1-99 decimal). If the number of channels is less 
than 8, the field will be filled with trailing 
spaces (hex code 20). 

The specified channels are scanned for' carrier or 
selective call. 

Carrier indication. 
Parameter X 

The frame must be transmitted only when there is a 

change between sensing carrier and sensing no 

carrier. The carrier sense itself should be "updated 

at least once per second. 

X = character 0 — > no carrier 

X = character 1 — > carrier 

Copy of own selective number. 
Parameter XXXXXXX 

Copy of the own selective call number. 
X is an ASCII coded digit 0-9. 

If the number of digits is less than 7, the number 
will be left justified and the XXXXXXX- field will be 
filled with trailing spaces (hex code 20). ' 
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X = S > transmitting (sending) 

X = M > receiving (monitoring) 



Note: Only the 'one-character function' can be included in an I 
command, e.g. H P1234567. 



Exhibit 



2, p. 786 



Cantel Mobitex- 



2/1056 - A 296 5175/2 Ue 



1990-02-26 A 



7 Signalling between HCD and terminal equipment connected to 
the MASC interface? '. 



7 . 0 General 



These chapters have been included because she network layer may 
be differently implemented in different terminal equipment. For 
any terminal equipment, connected to MOT via the MASC* interface, 
the MCEJ can be considered as a DCE for connection to the MOB I TEX 
network. A terminal can have a complete MOBITEX network layer or 
a simplified network layer, using different commands of the MASC 
protocol. 

A terminal connected ■ to the MCU must have the same terminal MAN 
number as the MCU. 

The terminal MAN must be associated to at least one output 
connection, either a MASC interface or another connection (e.g. 
a handset or a printer). 

All messages to groups, belonging to terminal MAM, should be' 
directed to the same output connection(s) as terminal MAN. 

The MCU has the responsibility towards the MOBITEX network 
according to the network . layer . 

In order to get the MOBITEX network layer in MCO and the 
terminal to interact correctly, the following chapters have to 
be considered. 



7.1 MPAK received from the network 

ROAMORD , FLEXREQ , INFOREQ and ESNREQ will be completely handled 
within the MCU without notifying any connected terminal. 

DIE and LIVE will be completely handled within the MCU but 
notified by FK-comraand(if handled) to connected terminals. 

All other correctly received MPAKs will, after normal handling 
in the MCU, be sent to the output connection where the addressed 
MAN is located. 

A fixed terminal can't receive a CONORD, therefore CONORD is to 
be converted to a CONREQ by the MCU. 
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7.2 MPAK received from a terminal 

Normally, if the MPAK passes the checks in the MCU, the MPAK 
will be sent to the network. The MCU should react and enter 
states as if the MPAK was generaced in che MCU (e.g. on CONREQ 
the MCU should enter a scace for call in progress, and should 
axso act according to the radio protocol for sending such MPAK) . 

If the checks fail, the MPAK should be returned to the -e-T*na" 
by an R-frame. 







CONHEA 


to be treated as a hook off -signal 






DISCON 


•- to be treated as a hook on-signal 






FLEXREQ 


if the personal subscription already 
— exist -in-flex-list the terminal will be 
informed by FK-frame. 






FLEXLIST 


to be returned to the terminal by an R- 
frame. 






BORN, 

info' 

ESNINFO 


to be returned to the terminal by an R- 
frame. 






LI NEON, 
LINEOFF 


to be returned to the terminal by an R- 
frame. 
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7.3 Connection between the MCU and the terminal 

The terminal is supposed to have a list of groupMAN's and a list 
of personal subscriptions (flexlist). In order to get the lists 
in the MCU equivalent to the list in the terminal, the following 
should be considered. 

Each time the link layer connection is established (by exchange 
of B-frames), the terminal will send: 



■ MANREQ ( 



P ?) to request MCU for the terminal MAN 



To answer this, the MCO sends the terminal MAN in the command 
MAN (command F £>). This answer should be sent immediately or, if 
another frame is currently being transmitted by the MCO, 
immediately after the transmission is completed. After that, 
the MCO will send the MASC_DEVICE command (F Q). 

The MCO should send: 

__. - GROOTLIST—- ^ 

- FLEXLIST 



to- set the list of groupMAN in. the 
terminal 



to set the flexlist in the terminal. 



The terminal will then handle the flexlist according to the 
specification, see Rl-09. 
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Example of start sequence when MCU starts. 
MCU TERMINAL 



MAN-frame 

MASC DEVICE- frame - 



GROUPLIST 
PLEXLIST 



Example of start sequence when TERMINAL starts: 

MCU TERMINAL 

■ — <-" -^B-f-rame 

< MANREQ-frarae 

MAN-frame ' > 

MASC_DEVICE-frame > 

GROUPLIST > 

■ FLEXLIST > 



Packets above the dotted line in each sequence 
belong to the link layer, and packets below the 
dotted line belong . to the network layer . 



7.4 Signalling between MCU and more than one terminal 

The MCU may have more than one MASC interface. 

All MASC interfaces should have the same start sequence as 
described in chapter "Connection between the MCU and the 
terminal" . 

The MCU handles all MPAKs and messages to different output 
connections where the MAN is located. 
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7.5 Description of a system with MASC interface. 
7.5.1 MCU connected to one terminal. 



MCO handles the terminal MAN, group MAN and' personal MAN with 
GROUPLIST and FLEXLIST in the start sequence. 

After the start sequence, all MPAKs are routed to the terminal. 
7.5.2 MCU connected to two terminals. 




MASC2 . 



TERMINAL2 



MCO handles the terminal MAN, group MAN and personal MAN with 
GROUPLIST and FLEXLIST in the start sequence. 

All terminals that have other terminal equipment connected, will 
have the same start sequence as described in chapter "Connection 
between the MCO and the terminal". These terminals should be 
considered as an MCD by the connected units. 

After the start up sequence ali MPAKs are routed to the current 
terminal . 
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Examples of start sequences. 
EXAMPLE 1. 

Lists, when MAN are correct and MCU starts. 

TERMINAL2 MCU TERMINAL 1 UNIT! CNIT2 

B-frame > 



MANREQ — > 

< MAN 

< MASC_DEVICE-frame 



-GROUPLIST 
GROUPLIST 

' FLEXLIST 
FLEXLIST 



Packets above the dotted line in the sequence belong 
to the link layer, and packets below the dotted line 
belong to the network layer. 
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EXAMPLE 2 






MANI is only in ONITl and TERMINALl . MAN2 is only in' MCU. 
MANI and MAN2 are personal subsciptions not included in MCO's 
flexlist. 




TERMINAL2 MCU 


TERMINALl UNIT1 UNIT 2 




B- frame > 

< MANREQ 

MAN > 

MASC_DEVICE > 

< B- frame 
MANREQ — > 

< MAN 

< MASC DEVICE-f rame 




< GRODPLIST 

GRODPLIST > 

< FLEXLIST 

■- — -• FLEXLIST > 






GROUPLIST > 

GRODPLIST > 

FLEXLIST > 

FLEXLIST > 




Note 1: The terminal/unitl/unit2 will replace former lists with 
these new lists. When replacing the flexlist the 
terminal/unitl/unit2 will decide if MANI and MAN2 are 
connected or disconnected. If connected , a loginreq is 
sent from MAN1 in unitl and a loginreq sent from MAN2 
in unit2. If not connected an presentation of the 
logout is sent to the user. 

Note 2: The application in ONITl has to send LOGINREQ for MAN1 
if it wishes to keep MAN1. 

Note 3: Packets above the dotted line in the sequence belonq to 
■the link layer, and packets below the dotted line 
belong to the network layer. 




MOBITEX MCD TERMINALl 

< LOGINREQ 

for MANI 

< LOGINREQ 

for MANI 


ONITl 0NIT2 

< LOGINREQ 

for MANI 




LOGINGRA — '—> 
for MANI 

LOGINGRA > 

for MANI 

LOGINGRA 
for MANI 
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EXAMPLE 3. 

TERMINAL! is starting the. connection. 



TERMINAL2 MCO 



TERMINALl DNIT1 



■ B-frame 
' MANREQ 



MAN > 

MASC_DEVICE > 

B-frame 



MASC DEVICE- 



' GROOPLIST 
GROOPLIST 

' FLEXL1ST 
FLEXLIST 



Note; Packets above the dotted line in the sequence belong to 
the link layer, and packets below the dotted line belong 
to the network layer. 
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7 . fi Fault 


situation in mobitex mobile stations. 


This is a recommendation of error message from* the MCU to the 
connected unit using a MASC interface. This error message is a 
response for a fault situation and sent as an error number in 
. the FK-command{see chapter "Information frame commands and 
functions"). 


Error numbers 0 - 4F is reserved for specific meaning. Error 
numbers 50 - FF is free to use. 


New meaning 


of error numbers is 


described in Rl-06. 


Error no: 


meaning : 






0 


reserved 






1 


DIE mode. 




An MPAK:DIE is received. No user 
traffic can be sent from the 
JWCU. 


2 


LIVE mode. 




An MPAK:L.IVE is received. . Dser 
traffic can be sent from the 
MCU. 


3 


SPEECH mode. 




The MCU is in speech mode and 
can not send any traffic except 
MPAK:CSUBCOM. 


4 


MANUAL mode- 




The MCU is in the manual mode 
and not in contact with mobitex 
network. . 


5 


reserved 






•6 


reserved 






7 


reserved 








reserved 






9 


reserved 






A 


Receiver buffer 


full, waiting for free buffer. 


B 


Buffer/memory free. 




C 


No memory, waiting for more memory. 


D 


reserved 






E 


reserved 






F 


reserved 
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Error no; 


meaning. 




Returned MPAK during die mode. 




Returned MPAK during speech, mode. 




Returned MPAK during manual mode. 




Returned MPAK during buffer full. 




reserved 




reserved 




Login request MAN already exist in 


17 


Loginrequest MAN is not possible, 


18 


MPAK sender MAN is not in TMAN or 


19 


reserved 


1A 


reserved 


IB 


reserved 


1C 


reserved 


ID 


reserved 


IE 


reserved 


IP. 


reserved 


20 - 4F 


reserved 
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8 MOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 

Rl-06, 27, 28, 45 

Hl-09, 9, 11, 12, 14, 15, 16, 17, 31, 32, 39 
Rl-16, 19, 21, 22, 23, 24, 26, 31, 32 
Rl-17, 26 



Below are the reference designations listed. 
Reference - Section 

Rl-01 Arrangement of the documents 

Rl-02 -MOBITEX System description 

Rl-03 General description of terminals 

Rl-04 Terminology 

Rl-05 References 

Rl-06 Network operator information 

Rl-08 Application layer 

Rl-09 Network layer 

Rl-11 Interface requirements, fixed terminals 

Rl-12 Other requirements, fixed terminals 

Rl-16 Link layer, mobile terminals 

Rl-17 Physical layer, mobile terminals 

Rl-18 Radio equipment, mobile terminals 

Rl-19 Other interfaces, mobile terminals 

Rl-20 Other requirements , mobile terminals 
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APPLICATION EXAMPLE 
OF HOW TO MAKE AN ALTERNATE CONNECTION VIA MCU 
FOR FIXED TERMINALS WITH MASC INTERFACE. 
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1 INTRODUCTION 

This document describes an example (i.e. not a 
specification) of an- MCU application. Its purpose is co 
aake it easier for -he manufacturers. ?or zhe 
understanding of chis document, =he reader has to be well 
informed about the Networx layer for terminals { reference 
Rl-09 ) and Link layer for mobile terminals { reference 
Rl-16 ). 

A fixed terminal may be directly connected to the MOBITEX 
network via a masc interface (MASC) s'ee document "Other 
interfaces" and appendix A "Commands". The aoplication in 
this document describes how sucn a terminal may be 
connected via an MCU, that handles the masc interface. As 
to the requirements of such a terminal, olease refer to 
chapter 7 in this document. 
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2 MCO WITH APPLICATION 

Figure 1 shows an MCU with its processes. Each process 
communicates with the other processes as is indicated by 
the arrows in the figure. 



AUDIO HANDLER 
"AUDIO" 



PRINTER HANDLER 



APPLICATION 
DIRECTOR 

"APP DIR" 



HASC HANDLER 1 
"MASC1" 



NETWORK LAYER 
"RADIO NET" 



In the centre of figure 1 is a process called APP_DIR, 
application director. This document will describe that 
process. 



The audio handler (AUDIO) handles an audio interface. 



Furthermore one may have "emergency handler", "terminal 
with small display handler" etc. 

The network layer (RADI0_NET) is a normal MOB I TEX network 
layer for mobile terminal, plus the additions made in 
chapter 7 (Requirements on network layer in MCU in this 
application). 
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The letters A, B and C represent different signalling 
sequencies. Observe that the HASC handler and the printer 
handler acts similarly towards the application director. 
All handlers act Ln the same way as an MASC handler 
towards the application director. 



Following terms are used in this document: 

- line handler common name for all handlers. 

MASC1 , MASC7 , AUDIO ... 



the mobile terminal's MOBITEX 
subscription number. 
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3 DESCRIPTION OP SIGNALS 

All signals that are handled by APP_DIR have che following 
structure: 

origin Original sender. Can be: line handler, 

RADIC_NET or 
APP_DIR. 

from Sender. Can be : line handler, 

RADIOJflET or 
APP .DIR. 



signal_status 



Signal status can be signal_status_olc or 
signal_status_not sent. 
Signal status is always set to 
signal_status_ok when the signal is 
created. 

If the RADIO_NET or any of the line 
handlers fails to transmit a signal, 
signal status will be set to 
signal_status-_not_sent. Then the signal 
is returned to APP DIR. 



Can be: S_hook_on, 
S_hook~off , 
S_MPAK, 

S_HPAK_sent_on_radio , 
S_returned_incor rect_MPAK , 
S_not_sent_MPAK 
S_line_up,~ 
S_line_down. 

If signal_type is'S_MPAK, S_not_sent_MPAK 
or S_returned incorrect_MPAK, it contains 
an MPAK in this field. 
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Description of the signal types: 



S line_up is sent by all line handlers to APP_DIR after a 
correct start or restart. 

If the line handler is an MASCJiandler , the starting up 
sequence will send a PRIM_MASC~f rame and an 
acknowledgement of this will bl received from the 
connected unit before S_line_up may be sent. 

If the line handler is a PRINTER , it is recommended that 
S_line_up is not sent until the modem signals say there is 
a printer connected. 



S line down 

S line down is sent by all line handlers to APP_DIR when 
tEe unit is disconnected. 

If the line handler fails to transmit a signal to the 
connected unit, S_line_down will be sent to APP_DIR 
together with the signal being returned. 



S MPAK 

S_HPAK is the normal signal being sent between line- 
handler and APP_DIR and between RADIOJJET and APPJDIR. In 
the normal case, signal status is signal_status_ok. But in 
the case when line handler or RADIOJJET fails to transmit 
the signal, signal status will be set to 

signal_status not_sent and the signal will be returned to 
APP_DIR. For further information see examples below 
{chapter 4) . 

When an S MPAK is received by the MASC-handler, the MASC- 
handler must send an M-frame to the connected unit 
according to the masc protocol. 

When an M-frame is transmitted from the connected unit , to 
the MASC-handler, the MASC-handler must send an S_MPAK to 
APP_DIR. 



S returned incorrect MPAK. 

S_returned_incorrect_MPAK is sent by APP DIR to line 
handler if an incorrect MPAK was received".. . 

If an MASC handler receives a S_returned_incorrect_MPAK, . 
this MPAK wiil be sent to the connected unit in an R-frame 
according to the masc protocol. 
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S not sent MPAK. 

S_not_senc_MPAK is sent by APP DIR to line handler if, for 
some reason, it is impossible to transmict a mnak on 



If an MASC handler receives a S_not_sent_MPAK, this MPAK 
will be sent so the connected unit in an N-frame accordinq 
to the masc protocol. 



S MPAK sent on radio 

S_MPAK_sent_on_radio is sent by RADIO NET to APP DIR when 
an MPAK has been sent via radio. Origin helps 4PP dir *- 0 
direct this signal to correct line-handler. When zhe MASC 
handler receives an S_MPAK_sent_on_radio, it uses ehe masc 
f_H-frarae to send the signal to connected unit. 



S hook off 

S_hook_off is sent by AUDIO to APP DIR at hook off. 
APP_DIR updates its registers and passes the sig-nal on to 
RADIO_NET . 

An MPAK CONREA, received by APP_DIR from connected unit, 
will not be sent to RADIO NET. Instead S hook off will be 
sent from APP_DIR to RADIO NET. 



S hook on 

Shook_on is sent by AUDIO to APP DIR at hook on. APP DIR 
updates its registers and passes the signal on to 
RADI0_NET. 

An MPAK DISCON, received by APP_DIR from connected unit, 
will not be sent to RADIO_NET. Instead S hook on will be 
sent from APP DIR to RADIO NET. ~ ~~ 
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4 EXAMPLES OF SIGNALLING IN THIS APPLICATION 

4.1 EXAMPLE 1: sending TEXT successfully 

Unit A sends an MPAK TEXT to a subscriber 3 in the MOBITEX 
network. Transmission via radio is successful. 



TERMINAL A 


MCD 




i 

MASCn 


APP DIR 




9 

.MASC 
protocol 


1 g 


A !> 

RADIO NET 

•I V 

ROSI 



signal signal_type 



origin from signal_status 



masc frame M 

S_MPAK MASCn 

S_MPAK MASCn 

6 are not handled in this document, 

S_MPAK_sent_on radio MASCn 
S_MPAK_sent_on~radio MASCn 
masc f?ame F_H 

Observe that origin = MASCn through the whole sequence. 
This gives APP_DIR an opportunity to route signals easier 
back to the sender. 



signal_status_ok 
signal_status_ok 



RADIO_NET signal_status_ok 
APP_dir signal_status_ok 
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4.2 EXAMPLE 2: sending TEXT unsuccessfully 

Unit A sends an MPAK TEXT to a subscriber B in the MOB I TEX 
network. APP_DIR discovers some kind of error. 



Q 



MASC 
protocol 



ROSI 



signal signal_type origin from signal_status 

1 masc frame M 

2 S_MPAK MASCn MASCn signal status ok 

3 S_returned- ~ 

I _incorrect_MPAK MASCn APP_DIR signal_sr.atus_ok 

4 masc frame R 

Observe that signal 3 has signal status set to 
signal_status_ok. Only line handlers and RADtO_NET may set 
signal status to signal_status_not sent. 
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4.3 EXAMPLE 3: sending TEXT unsuccessfully 

Unit A sends an MPAK TEXT to a subscriber 3 in the MOBITEX 
network. Transmission via radio fails. 



TERMINAL A 



D 





MCU 










2 






1 


MASCn 


> 


APP DIR 








< 






9 " 




8 


A U 


MASC 

protocol - 






RADIOJJET 










«l !« . 








ROSI " 





signal signal_type 



origin 



from 



signal_status 



signal_status_ok 
signal_status_ok 



masc frame M 

S_MPAK MASCn MASCn 

S_MPAK MASCn APP_D1R 

are not handled i.n this document. 
S_MPAK MASCn RADIO_NET signal_status- 

not_sent 

S_not_sent_MPAK MASCn APP_DIR i"ignal_status_ok 

masc frame N 
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4.4 EXAMPLE 4: sending TEXT unsuccessfully. 

Unit A sends an MPAK TEXT to a subscriber B in the MOBITEX 
network. Transmission via radio fails. The MCO fails to 
return the packet to unit A. 



HASC 
protocol 



signal signal_type 



irigm 



from 



signal_status 



masc frame M 

S_MPAK MASCn MASCn signal status ok 

S_MPAK MASCn APP_DIR signal~status~ok 

■ 6 are not handled in this document. ~ 
S_MPAK MASCn RADIO JIET signal_statqs- 

not sent 

S_not_sent_MPAK MASCn APP_DIR signal status ok 

masc frame N ~~ 
S_not_sent_MPAK . MASCn MASCn signal_status- 

_not_sent 

This sequence is the same as the one in example 3, except 
for signal 10. When receiving signal 10, APPJ3IR discovers 
that origin = from, i.e. the signal is returned even from 
the MASC handler. The only thing APP DIP. can do is to 
forget the signal. ~ 
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4.5 EXAMPLE 5: receiving TEXT successfully 
MCO receives an MPAK TEXT, addressed to MCU-MAN. 



MASC 
protocol 



signal signal_type origin from signal_status 

1-2 are not handled in this document. 

3 S_MPAK RADIO_NET RADIO_NET signal_status_ok 

4 S_MPAK RADIO_NET APP_DIR • signal_status_pk 

5 • raasc frame M ~ - . - 



The sequence above is valid if there is only one line 
handler. 

If an MPAK is addressed to the MCUJiAN, and there is more 
than one line handler, APP_DIR will send a copy of signal 
4 to each one of them. But~if the MPAK is addressed to a 
transferred MAN, APP_DIR will know on which of the line 
handlers this MAN can be reached. 
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4.6 . EXAMPLE 6: receiving TEXT unsuccessfully 

MCD receives an MPAK TEXT to unit 3. Transmission to unit 
B fails. There is only one recevier in this example and 
MPAK is addressed to MCO MAN. 



LXiKPLLMfUj a 



MASC 
protocol 



signal signal_type origin from signal_status 

1-2 are not handled in this document. 

3 S_MPAK RADIO_NET RADIOJJET signai_status_ok 

4 S~MPAK RADIO_NET APP_DIR signal_status_ok 

5 masc frame M 

6 SJ4PAK RADIO_NET MASCn. signal_status- 

~ not sent 



Observe that an MPAK r addressed to MCO_MAN or any MAN 
included in the grouplist, must not under any 
circumstances, be returned to the MOBITEX network. In this 
application, APP DIP. forgets the MPAK. 
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4.7 EXAMPLE 7: receiving 

MCD receives an MPAK CONREQ addressed to unit B. Onit 3 
responds with an MPAK CONREA after which the call can 
begin. Unit B terminates the call by sending an MPAK 
DISCON. 





MCU 




AUDIO | 


i 5 










4 








HASCn 










7 — > 


APP_DIR 








> 










12 


I 3 I 8 I 13 


MASC 
protocol 






RADIO NET 










I 2 I 9 ! 14 








ROSI 





signal signal_type 

1 
3 



signal_status 



2 are not handled in this document. 

S_MPAK RADIO_NET RADIO_NET signal_status_ok 



i_MPAK 

5 masc frame M 

6 masc frame M 

7 S_MPAK MASCn MASCn 

8 S_hook_off MASCn APP_DIR 
9-10 are not handled in this document. 



RADIO_net app_dir signaljstatus_ok 



signal_status ok 
signal_status~ok 



signal_status_ok 
signal_status_ok 



11 masc frame M 

12 S MPAK MASCn MASCn 

13 S_hook_on MASCn APP_DIR 

14 - 15 are not handled in this document 

Note: signal 1-5 contains MPAK CONREQ. 

signal 6-7, 9-10 contains MPAK CONREA 
signal 11 - 12, 14-15 contains MPAK DISCON 

. In this application S_hook_on and S_hook_off are always 
sent, instead of MPAK DISCON and MPAK CONREA, to the 
RADIO NET. 
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4.8 EXAMPLE 8: receiving CONREQ 

MCO receives an MPAK CONREQ addressed to unit B. The audio 
interface generates a hook off after which the call can 
begin. The call is' terminated by the audio interface 
generating an hook on. 



HASC 
protocol 



3 i7 111. 



2 |8 12 



signal signal_type 



origin 



1-2 are not handled in this document. 

3 SJ4PAK RAD10_NET RADIO_NE? 

4 SJ4PAK RADIO_NET APP_DIR 

5 masc frame H 

6 S hook off AUDIO AUDIO 

7 S~hOOk~off AUDIO APPJ3IR 
8-9 are not~handled in this document. 

10 S_hook_on AUDIO AUDIO 

11 S_hook_on AUDIO APP_DIR 

12 - 13 are not handled in this document 

14 SJtPAK RADIO_NET APP_DIR 

15 masc frame M 

Note: signal 1-5 contains MPAK CONREQ 
signal 8-9 contains MPAK CONREA 
signal 12 - 15 contains MPAK DISCON 



Observe that APP_DIR generates MPAK DISCON to unit B 
This is to avoid blocking situations in unit B. 



! signal_status_ok 
signal_status_ok 



signal_status_ok 
signal_status_ok 



signal_status_ok 
signai_status~ok 



signal_status_ok 
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5 LISTS OP SIGNALS 




Signals that are sent within the MCU, interfaces A, B and 
C in figure L, are iisted below. The signals are divided 
into categories of' normal and returned signals. 


5,1 Interface A 




5.1.1 Signals sent from APP_DIR to line handlers 


Normal signals 




SJ4PAK 

origin = 
from = 
signal status = 
signal type = 
MPAK 


creator of this signal 
APP_DIR 

signal status ok , 
S MPAK 

MPAK in question 


S_not_sent_MPAK 
~" "origin = 
from = 
signal status = 
signal type = 
MPAK 


creator of original MPAK 
APP_DIR 

signal status ok 
S_not_sent_MPAK 
MPAK in question 


S_returned^incorrect_MPAK 
origin ~ = 

signal_status = 
signal type = 
MPAK 


creator of original MPAK 
APP DIR 

signal_status_ok 
S_returned_incorrect_MPAK 
MPAK in question ~~ 


S_MPAK_sent_on_radio 

origin ~ - . 
from = 
signal status = 
signal_type = 


creator of original MPAK 
APP_DIR 

signal_status_ok 
S_MPAK_s ent_on_r adi o 
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5.1.2 Signals sent from line handlers to APPJDIR 




Normal siqnals 






S line up 

origin = 

signal_status = 
signal_type = 


line handler in question 
origin 

signal_status_ok 
S_line_up 




S_line_down 

origin . = 
from = 
signal_status = 
signal^type ■ 


line handler in question 
origin 

signal_status_ok 
S_line~down ~* 




S_MPAK 

origin -- = 
from = 
signal status = 
signal~type = 
MPAK 


line handler in. question 
origin 

signal status olc 
S_MPAK~* 

MPAK in question 




Returned sicrnals 






SJLPAK 

from = 
signal status = 
signal type « 
MPAK ~ = 


no change in this field 
line handler in question 
signal status not sent 
SJ4PAK 

MPAK in question 




S_MPAX_sent_on_radio 

origin ~ = 
from 

signal_status = 
signal~cype = 


no change in this field 
line handler in question 
signal_stacus_nat sent 
S_MPAK_s e n t_o n_r aa i o 




S_returned T incorrect_HPAK 

from = 
signal_status = 
signal~type = 
MPAK ~ 


no change in this field 
line handler in question 
signal_status_not_sent * 
S_returned_incorrect_MPAK 
MPAK in question ~ 




S_not_sentJHPAK 

origin = 
from = 
signal status = 
•signal type 
MPAK 


no change in this field 
line handler in question 
signal status not sent 
S_not sent_MPAK ~ 
MPAK in question 









Exhibit 



2, p. 815 



19 



Cantel Mobitex- 


. - I 
1/1056 - A 296 5175 Ue 


"1990-02-23 j"".MTS19B.l 




5.1.3 Signals from APPJDIR to AUDIO 




All signals listed in 5.1.1 






5.1.4 Signals from AUDIO 


to APPJ3IR 




All signals listed in 


5.1.2 


plus the following: 




S_hook_off 










origin 






AUDIO 




from 






AUDIO 




signal_status 


- 




signal_status ok 




signal~type 


- 




S_hook_off 




S_hook_on 










origin 






AUDIO 




from 


= 




AUDIO 




signal status 






signal status ok 




signal_type 


= 




S_hook_on ~ 




5.1.5 Signals from 


APP„ 


_DIR to RADIO_NET 




Normal signals 










S_MPAK 

origin 






creator of this signal 




from 






APP_DIR 




signal status 






signal status ok 




signal type 






S_MPAK 




MPAK 






MPAK in question 




S hook on 










- origin 






AUDIO 




from 






APP_DIR 




signal status 






signal_status_ok 




signal_type 






S_hook_on ~ 




S_hook_off 










origin 






AUDIO 




from 






APP_DIR 




signal_status 






signal status ok 




signal_type 






S_hook~o£f 
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5.1.6 Signals from RADIO_NET to APP_DIR . 



Normal signals 



origin 
from 

signal_status 
signal type 
MPAK 



RADIO_NET 
origin . 

s ignal_s ta tus_ok 
S_MPAK 

MPAK in question 



Returned signals 



origxn ■ 
from 

signal_status 

signal~typs 

MPAK 



no change in this field 
HADIOJJET 

signal status_not_sent 
S_MPAK~ 

MPAK in question 



S_hook_on 
~~ origin 
from 

signal_status 
signal_type 



AUDIO 
RADIOJIET 

signal_status_not_sent 
S_hook_on 



l_hook_off 
origin 
from 

signal_status 
signal~type 



AUDIO 
RADIOJIET 

signal_status_hot_sent 
S hook_off 
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6 REGISTERS IN APP_DIR 




Four registers are kept in APPJDIR: 


6.1 Register number one 


: MCU_REG 



The register called MCU_REG has the structure shown in the 
figure below. 



LINE 


MASC1 MASC2 MASC3 AODIO PRINTER 


MAY / MAT NOT 
INACTIVATE MCD 




LINE DP / 
LINE DOWN 




MSG 
TYPE 


TEXT 




STATUS 




DATA 




HP DATA 




SPEECH 




EMERGENCY 




EXTPAK 





line 

Contains the line handlers that exist in this 
application. This is static information. 

msq type 

Tells which MPAKs, addressed to MCU_MAN or any MAN in the 
grouplist, will be received by' the Tine handler. As an 
example, there is nothing to prevent that MPAK- TEXT is 
received by a number of line handlers. In the speech 
connection case, in this particular application, only 
one line handler can be enabled. Msg type contains static 
information. 

may/may not inactivate MCD 

Tells whether the line handler in question is allowed to 
inactivate MCU with an MPAK DTESERV . INACTIVE . Normally,, 
only one (or very few) of the line handlers should be 
allowed to do this. This is static information. 
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line up/down 

Contains information about each of the connected line 
handlers. This information is dynamic. 



The figure below shows how the MCU_REG may be used. 



LINE 


MASC1 MASC2 MASC3 ADO 10 PRINTER 


MAY / MAY NOT 
INACTIVATE MOT 


MAY NOT NOT • NOT NOT 


LINE UP / 
LINE DOWN 


UP OP DOWN OP OP 


MSG 
TYPE 


TEXT " 


XXX X 


STATUS 


X 


DATA 


X 


HP DATA 


X 


SPEECH 


X 


EMERGENCY 


X 


EXTPAK 


X 



In this case, only MASC1 is allowed to inactivate the MCO. 
All line handlers, except for MASC3 , are connected and 
intact. When APP_DIS receives an MPAK TEXT from MOBITEX 
network, it will be sent to MASC1, MASC2 and PRINTER. Since 
MASC3 does not have status line_up, it does not receive any 
MPAKs. Received MPAK STATUS is to be sent to. AUDIO. Other 
MPAKs are to be sent to MASC1. 

Observe that APP_DIR does not keep information of if mcu is 
active or inactive. Nor does APP_DIR know if RADIO NET has 
received an MPAK DIE from the MOBITEX network. It Ts che 
responsibility of RADI0_NET to keep information about this . 
If RADI0_NET notes which APP_DIR is not allowed to send to 
the MOBITEX necwork, the packets are returned to APP DIR 
with signal status set to signal_status_not_sent . 
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6.2 Register number two: FLEXLIST 

The FLEXLIST register has the structure shown in the figure 
below. 



MAN - The HOB I TEX subscription number of the transferred 
subscriber. Up to seven MAN-numbers are allowed. 

LINE "-""The line handler to which the transferable has 
transferred. . 

STATUS - Tells login status. 

It can be: UNDER_LOGIN - the login sequence is not 
yet finished 
OK_LOGIN - the login sequence is 
finished and accepced 



6.3 Register number three: GROUPLIST 

The GROUPLIST contains a list of group MAN numbers 
MAN numbers is allowed. 



6.4 Register number four: CONNECTION_reg 

CONNECTION REG keeps information about the status of the 
speech line. It contains the following information: 

CONNECTION_STATUS 
CONNECT ION_P ART Y_HERE - 
CONNECTION_OTHER_PARTY 
CONNECTION CONN ID 



•can be free, busy or 
waiting_for_hook_of f 



MAN number for connection part in 
the MCU 



MAN number for 
part 



:he other connection 



connection identity for current 
speech line connection 



Exhibit 2, p. 820 



Cantel Mobitex- 



• A 296 5175 Ue 



1990-02-23 



7 REQUIREMENTS ON THE NETWORK LAYER IN- MCO 

Requirements on Che network layer in MCO (RADIO_NET) are 
listed below: 

1. Everything applicable to mobile terminal in document 
MOBITEX network layer for terminals, 5/1056 - A 296 
5171. 

2 All MPAKs that the application wants to send via radio 
and network layer to 

- be acknowledged to the application if the transmission 
was successful, 

- be returned to the application if the transmission 
failed. 



The signals hook_on and hook^off will be returned to the 
application if the transmission via radio "fails. 

The following MPAKs, received by the MCO via radio, to 
be sent to the application: 

- all MPAKs of class PSOBCOM 

- all MPAKs Of class PSOSCOM. 

Note that a transferred subscriber, connected to 
the MCU via an MASC handler, can be. emergency 
receiver. 

- following MPAKs, belonging to the class CSDBSOM: 



+ ADDCONREQ 
+ SOSCONREQ 
+ EXTCONREQ 
+ CONORD 
+ DISCON 

following MPAKs, belonging to the class DTESERV: 
+ LOGINREQ * ** 

+ LOGINREF ** 
+ LOGOOTORD ** 
+ LOGINGRA ** 
+ FLEXLIST ** 
+ TIME 

+ GROUPLIST ** 
+ SOSRX * *** 



These MPAKs can only have MPAK states that are not OK. 
These MPAKs concern flexlist and grouplist. They are 
handled by the network layer and sent to the 
application. The reason for this is that the application 
has copies of flexlist and grouplist. 
' Only if a terminal, connected to the MCO, has an 
emergency receiver transferred to it. 
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8 REQUIREMENTS ON A FIXED TERMINAL 




The recruirements for a fixed terminal which is able to 
connect to the MOBITEX network as well as the MCU are as 
follows . 




Link layer 






Frames in the masc protocol for implemented: 




All control frames 


ACK, RACK, NACK, SENS, SACK 




Following information frames: 

B r M, E, R, F_P, F_Q, N 




Network layer- 






The MOBITEX network considers a fixed terminal, connected 
via an MCU, as a mobile terminal. This has the following 
consequencies as to which MPAKs may be sent and received by 
the terminals. 




class PSUBCOM: 

The terminal is allowed to send and receive all MPAKs 
in this class. 




class -PSOSCOM: 

An emergency sender can be a mobile subscriber or a 
transferable subscriber which is transferred to a 
mobile subscriber. A receiver can be a fixed terminal 
subscriber or a transferable subscriber. 
All emergency senders can send SOS and receive SOSACK. 
Furthermore, all mobile terminals are be able to 
receive SOS and SOSACK addressed to All terminals 
group MAN. 




class CSUBCOM: 

If the fixed terminal has one line for speech line 
connection, the following MPAKs can be received and 
sent: 

CONREQ 




SOSCONREQ 
ADDCONREQ 






EXTCONREQ 

CONREA 

DISCON 






• Connection to group will be made by the MCU by 
converting CONORD to CONREQ. 
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Class DTESERV: 

Following MPAKs may be sent: 
LOGINREQ . 
LOGOUT 
ACTIVE 
INACTIVE 
VICESOSRX 
SOSRX * 
FLEXLIST * 

* Only if the sender is a transferable subscriber. 



Following MPAKs shall be received: 
LOGINREQ 
LOGINGRA 
LOGINREF 
LOGOOTORD 
VICESOSRX 
— SOSRX — — ■ ' -- - 
GROCIPLIST 
. FLEXREQ 
TIME 



When the network layer receives masc frame N 'from the 
masc interface, it acts in the same manner as if the 
MPAK never leaved the fixed terminal. 
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9 PSEODO CODE FOR APP_DIR 

In this pseudo code all procedures start with "P_", and all 
functions with "F 



REPEAT 

Wait for input . 
CASE input signal_type OF 
S MPAK sent on radio 
"IF from =~RADIO_NET THEN 

send this signal to origin 
ELSE 

forget this signal 
END IF 
S_hook_on 

P_hook_on 
S_hook_off •• 
P_hook_off 
S_lTne_up 

~P line up 

S_line_^down 
~P line down 
S MPAK ~ 

~P_MPAK 
conord_timer 

CONNECTION_STATUS = free 
otherwise 

forget this signal 
END CASE input signal OF 
UNTIL forever 



P_hook_on 

IF ( from = AUDIO ) AND ( CONNECT I ON_STATUS <> free ) 
THEN 

send this signal to RADIO_NET 

send signal S MPAK with MPAK = DISCON to 

CONNECTION_LINE 

(MPAK. sender = CONNECTION_OTHER_PARTY 
MPAK. addressee = CONNECT ION_PARTY_HERE 
MPAK. type dependent. line number =~0 
MPAK.type~dependent.CONN_ID=CONNECTION CONN ID) 
C0NNECTION_STAT0S = free 
ELSE 

forget this signal 
END IF (from = AUDIO) AND { CONNECT ION_STATUS ofree). 
END P hook on 
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PJiook off 

IP from = AUDIO THEN 

IF CONNECTION_STATUS = waiting f or_hook_of f THEN 
CONNECTION STATUS = busy 
send this signal to RADIOJNET 
reset conord_timer 
ELSE 

forget this signal 
END IF CONNECTION_STATUS = waiting for hook_off... 
ELSE 

IF (from=RADIO NET) AND ( signal_status = 

~ signal_status_not_sent) THEN 

forget this signal 

send signal S_MPAK with MPAK = DISCON to 
CONNECTION LINE 

( MPAK.sencTer = CONNECTION_OTHER_PARTY 
MPAK. addressee = CONNECT I ON_P ART Y_HERE 
MPAK. type dependent. line numher = 0 
MPAK. type~deoendent. CONN ID = CONNECTION_C0NN_ID ) 
CONNECT ION_STATDS = free 
- ELSE 

forget this signal 
END IF (from = RADIO NET) AND (signal_status =. . . ) 
END IF from = AUDIO..." 
END P hook off 



P_line_down 

mark origin in MC0_REG as line_down 

FOR all MAN in our flexlist pointing at origin DO 

send signal S_MPAK with MPAK = logout to RADIO_NET 
( MPAK. sender = MAN in question from flexlist 
MPAK. addressee = the MOBITEX network 
MPAK.type_depehdent part = MCD_MAN ) 
remove MAN in question from our flexiist 
END FOR all MAN in our flexlist pointing... 
END P_line_down 



P_line_up 

send signal S MPAK with MPAK = grouplist to origin 
( MPAK. sender = the MOBITEX network 
MPAK. addressee = MCU_MAN 
MPAK.type_dependent_part = our grouplist ) 
send signal S_MPAK with MPAK « flexreq to origin 
( MPAK. sender = the MOBITEX network 
MPAK. addressee = MCU_MAN ) 
mark origin in MCU_REG as line_up 
END P_line_up 
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P_HPAK 

IF signal status = signal_status ok THEN 
IF from~= HADI0_NET THEN 

P_MPAK_f rom_radio 
ELSE 

P_HPAK_f rom_other 
END IF from = RADIO_NET ... 
ELSE 

IF origin = from THEN 

forget this signal (can't send this signal in any 
direction ) 

ELSE 

IF origin = RADIO_NET THEN 

forget this signal (Never send back MPAK to 
network) 

ELSE 

IF MPAK.unknown_f = 0 THEN 
CASE MPAK.packet_ciass OF 
PSUBCOM,PSOSCOM 

signal status = signal_status_ok 
signal'type = S_not_sent_MPAK 
send this signal to origin 
CSDBCOM 

CASE MPAK. pack et_type OF 
CONREQ , ADDCONREQ , SOSCONREQ , EXTCONREQ 
signal_status = signal_status_ok 
signal_type = S_not_sent_MPAK 
send this signal to origin 
CONNECTION_STATOS = free 
otherwise 

forget this signal 
END CASE HPAK.packet_type. . . 
DTESERV - 
CASE MPAK.packet_type OF 
VICESOSRX.SOSRX 

signal_status = signal_status_ok 
signal_type = S_not_sent_MPAK _ 
send this signal to origin 
LOGINREQ 

remove MPAK.type_dependent_part from our 
flexlist 

signal_status = signal_status_ok 
signal_type = S_not_sent_MPAK 
send this signal to origin 
otherwise 

forget this signal 
END- CASE MPAK.packet_type. . . 
END CASE MPAK. class. . . 
ELSE 

forget this signal 
END IF MPAK . unknown_f . 
END IF origin. . . 
END IF origin. . . 
END IF signal_status. . . 
END P MPAK 
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P_MPAK_from_other 

mark origin in MCU REG as line up 
CASE MPAK. packet class OP ~ 
PSUBCOM.PSOSCOM ~ 

IP MPAK . unknown_f = 1 THEN 

IF (F_get_receiver_MAN in our grouplist ) OR- 
[F_get_receiver_MAN = MCU_MAN ) THEN 

forget this signal 
ELSE 

IF F_get_receiver_MAN in our flexiist THEN 
remove F_get receiver_MAN from our flexiist 
send signal SJMPAK with MPAK = LOGOUT to RADIO NET 
( MPAK. sender = F_g'et receiver_MAN ~ 
MPAK. addressee = the MOB I TEX network 
MPAK.type_dependent_oarf = MCU MAN ) . 
END IF F_get_receiver_MAN in our* flexiist ~ 
send this signal to RADIO NET 
END IF tF_get_receiver_MAN In our grouplist... 
ELSE ( IF MPAK. unknown f = 1 ...) 

IF (MPAK. state <> OK*") OR { MPAK.digital_f =1 ) THEN 

signal_type = S_returned_incorrect_MPAK - 

send this signal to origTn 
ELSE 

IF (F_get_transmitting_MAN = MCO_MAN ) or 
(F_get_transmitting_man in our flexiist with status 
ok_login } THEN 

send this signal to RADIO NET 
ELSE 

send signal S_MPAK with MPAK = LOGODTORD to origin 
(MPAK. sender = the MOBITEX network 
MPAK. addressee = MCU_MAN 

MPAK . type dependent jpart= P_get transmittina MAN) 
signal_type = S_not_sent_MPAK ~ "~ 
signal~~status =~signal_status_ok 
send this signal to origin 
END IF (F_get transmitting MAN = MCU MAN... 
END IF MPAK. state. . . ~ ~ 

END IF MPAK. unknown f... 
CSDBCOM 

CASE MPAK. packet type OF 
CONREQ , ADDCONREQ7SOSCONREQ , EXTCONREQ 
IP ( MPAK.unknown_f - 0 ) and 
{ MPAK.mailbox_f = 0 ) and 
( MPAK.sendlist_f = 0 ) and 
( mpak. state = OK ) THEN 
IF (F_get_transmitting_MAN = MCU_man ) or 
(F_get_transmitting_MAN is in our flexiist with 
status~ok_login ) 
THEN 

IF CONNECTION STATUS = free THEN 
CONNECTIONjTine = origin 
C0NNECTION_status = busy 
send this signal to RADIO_NET 
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signal_type = S_not_sent_MPAK 
signal_status = signal status_ok 
send this signal to origin 
END IF"CONNECTION_STATUS = free... 
ELSE 

send signal SJtPAK wich MPAK = LOGOUTORD to 
origin 

( MPAK. sender = the MOB I TEX network 
MPAK. addressee = MCU_MAN 
MPAK.type_deDendent_part = 
F get transm!tting_MAN ) 
signal_type * S,_no<:_sent'_MPAK 
signal_status = signai status_ok 
send this signal to origin 
END IF (F_get transmitting MAN = MCU MAN... 
ELSE 

signal_type = S_returned_incorrect_MPAK 
send this signal to origin 
END IF ( MPAK.unknownjE =0... 
CONREA 

IF ( CONNECTION STATUS "= waiting for hook_off) and 
( origin = CONNECTION^ ine ) THEN 

forget this signal ~ 
. send signal SJiook off to RADIO_NET 

CONNECT ION_STATDS = busy 

reset conord_tiraer 
ELSE 

forget this signal 
DISCON 

IF ( CONNECTIONJ3TATUS <> free) and 
( origin = CONNECTION. line ) THEN 

forget this signal 

send signal hook on to RADIO NET 

CONNECTION_STATUS = free 
ELSE 

forget this signal 
otherwise 

forget this signal 
END CASE MPAK.packet_type... 
DTESERV ~ 
CASE MPAK.oacket type OF 

LOGINREQ , LOGOUT , ACTIVE , INACTIVE , VICESOSRX , SOSRX , FLEXLIST 
IF (MPAK. state = ok ) AND 
( MPAK.digital_f = 0 ) AND 
( MPAK,roailbox_f = 0 ) AND 
( MPAK.sendlist_f = 0 ) AND 
( MPAK. unk nown_f = 0 ) AND 
( MPAK.extern_f = 0 ) AND 
• ( MPAK. addressee = MOB I TEX network ) THEN 
CASE MPAK.oacket_type OF 
LOGINREQ , ACTIVE , INACTIVE , FLEXLIST 
IF MPAK. sender = MCU MAN THEN 
CASE MPAK.packet_type OF 
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LOGINREQ 

IF MPAK.type_dependent_part in our flexlist 
with status = ok_login THEN 

send signal S_MPAK with MPAK LOGINGRA to 

origin 

( MPAK. sender = the MOBITEX network 
HP AK. addressee = MCU_MAN 
MPAK. type_dependent_part = 
=<old>MPAK.type_dependent_part ) 
forget this signal 
ELSE 

IP more space exists in our flexlist THEN 
mark MPAK. type dependent_nart in our 
flexlist 

with status=under_login and line = 
origin 

send this signal to RADI0_NET 
■ ELSE 

. signal_type = S_not_sent_MPAK 
signal~status = - signal_status_pk 
— -.send this signal to origin ~ 
END IF more space in our flexlist... 
END IF MPAK.type_dependent_part in our... 
ACTIVE, INACTIVE 

IF origin may inactivate THEN 
P_line down 

send this signal to RADIO NET 
ELSE 

P_line_down 

forget this signal 
END IF origin may activate/inactivate... 
FLEXLIST 

FOR all MAN in MPAK . FLEXLIST not in our 
flexlist 
with status ok_login DO 

send signal S_MPAK with MPAK = logoutord 
to origin 

( MPAK. sender = the MOBITEX network 
MPAK. addressee = MCUJtAN 
MPAK.type_dependent_part = MAN in 

~ question ) 

END FOR all MAN in MPAK. FLEXLIST not in our.., 
forget this signal 
END CASE MPAK.packet_type 
ELSE ( IF MPAK. sender = MCO_MAN) 

signal_type = S_returned^_incorrect_MPAK 
send this signal to origin 
END IF MPAK. sender = MCU MAN. . . 
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VICESOSRX,SOSRX 

IF MPAK. sender in our flexlist. with status 
ok_login THEN 

send this signal to RADIO_NET 
ELSE 

signal_type = S_not_sent_MPAK 
signal_status = signal_status_ok 
send this signal to origin from 
END IF MPAK. sender in our flexlist with status. 
LOGOUT 

IF MPAK. sender in our flexlist with any status 
THEN 

delete MPAK. sender from our flexlist 
MPAK.type_dependent_part = MCUJtAN 
send this signal to~RADIO NET ' 
ELSE 

forget this signal 
END IF MPAK. sender in our flexlist ... 
END CASE MPAK. packet type... 
ELSE 

signal.-fc-ype-^ S_returned_incorrect_MPAK 
send tHis signal to origin ~ 
END IF (MPAK. state = ok... 
otherwise 

signal_type = S_returned incorreet_MPAK 
send this signal to origin 
END CASE MPAK.packet_type.. . 
END CASE MPAK. Class. . . 
END P MPAK from other 



P_HPAK_from_radio 
CASE MPAK. class OF 
PSUBCOM,PSOSCOM 

IF F get_receiver MAN in our flexlist THEN 

send this signal to line in question 
ELSE 

IF ( F_get_receiver_MAN = MCU_MAN ) OR 
( F_get_receiver_MAN in our grouplist ) THEN 
CASE MPAK. class OF 
PSOBCOM 

CASE MPAK.packet_type OF 
TEXT 

P_copy_and_send_signal{ text ) 
STATUS 

P_copy_and_send_signal( status ) 
HPDATA 

P_copy and_send signal ( hpdata ) 
DATA 

P_copy_and_send_signal( data ) . 
EXTPAK 

P_copy_and_send_signal (EXTPAK) 
otherwise ~" ~ 

forget this signal 
END CASE MPAK. packet type... 
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IF ( MPAK.packet_type = SOS or SOS INFO ) 

AND ( MP All t addressee = all terminal group MAN ) 

THEN 

IF MPAK. sender in out flexlist THEN 

send this signal to line in question 
ELSE 

P_copy_and_send_signal( emergency ) 
END IF MPAK. sender in our flexlist... 
ELSE 

P_copy and^send_signal{ emergency ) 
END IF {~MPAK. packet type .=. SOS or SOSINFO.. 
END CASE MPAK. class.. 
ELSE 

( This case can not appear; the network layer shall 

take care of unknown MPAKs from the network) 
MPAK.unknown_f = 1 
send this signal to RADIO NET 
END IF ( F_get_receiver_MAN~= MCD_MAN . . . 
END IF F_get_receiver MAN in our flexlist... 
CSUBCOM ...... _. 

CASE MPAK.packet_type OF 

CONREQ , ADDCONREQ , SOSCONREQ , EXTCONREQ 
IF MPAK. state <> ok THEN 

P discon 
ELSE 

IF F_get_receiver_MAN in our flexlist THEN 
CONNECTION_STATOS = waiting for_hook_off 
CONNECTION LINE = line in question from flexlist 
CONNECTION~PARTY_HERE = MPAK. addressee 
CONNECTION_OTHER_PARTY = MPAK. sender 
CONNECTION_CONN_ID =MPAK. type_dependent . conn_id 
send this signal to line in question 

ELSE 

IF F_get_receiver_MAN = MCO_MAN THEN 

CONNECTION_STATUS = waiting_for_hook_df f • 
CONNECT I ON_P ARTY_HERE = MPAK. addressee 
CONNECTION OTHEH_PARTY = MPAK. sender 
CONNECTION~CQNN_ID =MPAK. type_dependent . conn_id 
send this signal to first line in MCtJ_REG with 
(line_status = up) AND (msg_type = speech) 
IF no such line THEN 
forget this signal 

CONNECTION_STATUS = waiting_for_hook_of f 
send signal S_hook on to RADIO_NET "~ 
ELSE 

CONNECTION_LINE = line in question from 
MCU_REG 
END 
ELSE 

forget this signal 
send signal S hook_on to RADI0_NET 
END IF ( F get_receiver_MAN = MCU_MAN... 
END IF F GET~receiver_MAN in our flexlist... 
END IF MPAK. state <> ok 
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CONORD 

IP CONNECTION STATUS = free THEN . 

IF F get receiver MAN in our grouplist THEN 
MPAK . pack et_t ype = CONREQ 
CONNECTIONjSTATUS = waiting_£or_hoak_o£ £ 
CONNECT I0N_PART2_HERE = HPAK. addressee 
CONNECTION_OTHER_PARTY = MPAK. sender 
CONNECT ION_CONN_I D= MPAK . type_dependent . conn_id 
send this signal to first line in MCU_REG with 
{ line_status = up ) AND { msg_type = speech ) 
IF no such line THEN 

forget this signal 

CONNECTION STATUS = free ' 

send signal S hook on to RADIO_NET 
ELSE ~ ~ 

CONNECTION^ INE = line in question from HCO_REG 

set timer: conord_timer 
END 
ELSE 

forget this signal 
send signar S_hook_bh to RADIO_NET 
END IF F get_receiver_HAN in our grouplist... 
ELSE 

forget this signal 
END IF CONNECTION_STATUS = free... 
DISCON 

P_discon 
otherwise 

forget this signal 
END CASE MPAK. packet type... 
DTESERV 

CASE MPAK.packet_type OF 
LOGINREQ , LOGINREF , LOGOUTOHD 

IF MPAK.type_dependent in our flexlist THEN 
send this signal to line IN QUESTION 
remove MAN in question from our flexlist 
ELSE 

forget this signal 
END IF MPAK.type_dependent in our flexlist THEN 
LOGINGRA 

IF MPAK. type dependent in our flexlist THEN 
mark in our flexlist status = ok_login 
send this signal to line in question 

ELSE 

send signal S_MPAK with MPAK = logout to RADIO_NET 
( MPAK. sender = MCU_MAN 
MPAK. addressee = MOB I TEX network 
MPAK. type dependent_part = MAN in question 
■ END IF MPAKTtype dependent in our flexlist 
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FLEXLIST 

FOR all MAN in this signal who are not in our fiexlist 
send signal S_MPAK with MPAK = logout to RADIQ_NET 
( MPAK. sender = MCU MAN 
MPAK. addressee = ""MOBITEX network 
MPAK. type dependent_part = MAN in question) 

END 

FOR all MAN in our fiexlist who are not in this signal 
send signal S_MPAK with MPAK = logoutord to line in 
question ~ 

{ MPAK. sender = MOBITEX network 
MPAK. addressee = MCnjtAN 

MPAK.type_dependent_part = MAN in question ) 
remove MAN in question from our fiexlist 
END 
TIME 

send a copy of this signal to all lines 
GROOPLIST . 

store grouplist from this signal in our register 
send a copy of this signal to all lines 

SOSRXr-VICESOSRX - - - - 

IP P_get_receiver_MAN in our fiexlist THEN 

send this signal to line in question 
ELSE forget this signal 
END CASE MPAK. packet type OF... 
END CASE MPAK. class..."" 
END P_MPAK_f rom_radio 



P_copy_and_send_signal ( type } 

send a copy to all lines in MCUJREG with 

( line_status = up ) and ( msg_type = type ) 

END p_copy_and_send_signal 



P_discan 

IF CONNECTION STATUS <> free 

send this sTgnal to CONNECTION^ INE 
. CONNECTION_STATUS = free 
ELSE 

forget this signal 
END 

END P discon 



Exhibit 2, p. 833 



Cantel Mobitex- 



1/1056 - A 296 5175 Ue 



1990-02-23 B 



F_get receiverJMAN 
CASE MPAK. state OF 
ok,from_mail 

F_get_receiver_MAN = MP AK. sender 
otherwise 

F_get receiver HAN = MPAK. addressee 
END CASE ~ 
END F_get_receiver_MAN 



F_get_transmitting_HAN 

IF MPAK.unknown_f = 0 THEN 

F_get_transraitting MAN = MPAK. sender 
ELSE 

F_get_transmitting MAN = F get receiver MAN 
END - - - 

END F_get_transmitting_MAN 
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10 MOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 



Below are the reference designations listed. 
Reference Section 

Rl-01 .- Arrangement of the documents 
Rl-02 MOBITEX System description 

Hl-03 General description of terminals 

Rl-04 Terminology 
Rl-05 References 
Rl-06 Network operator information 

Rl-08 Application layer 

Rl-09 Network layer 

111-11 Interface requirements-, fixed terminals 

Hl-12 Other requirements, fixed terminals 

Ri-lS Link layer, mobile terminals 

Physical layer, mobile terminals 
R1-1B Radio. equipment, mobile terminals 

Rl-19 Other interfaces, mobile terminals 

81-20 Other requirements, mobile terminals 
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HOBITEX 

General requirements, mobile term. • 



The general requirements for MOBITEX mobile terminals are 
described in this document. These include environmental 
requirements, power supply requirements, the minimum 
requirements for controls and indicators and special 
requirements in connection with the type approval testing. 
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1 ENVIRONMENTAL REQOIREMENTS 

The equipment must be operational also under the extreme 
temperature' conditions. No error functions which can 
interfere with the operation of the MOBITEX network must 
occur under any environmental condition. 



1 . 1 Temperature 

The normal operational temperature" range: 

+15 to +35 degrees c' 
The extreme operational temperature range: 

-25 to +55 degrees C. 

The equipment should be such that it is not damaged by 
storage in the temperature range of: 

-40 to +70 degrees C. 

1.2 Relative humidity 

Mobil terminal should be able to withstand 20-75% RH. 

1.3 Vibrations 

The equipment should be able to withstand a vibration test 
in accordance with IEC publication 68-2-6: 

10 - 55 Hz +/- 0,15 mm movement. 

55 - 150 Hz 20 m/s square acceleration. 

Sweep rate: 1 octave per. minute 

Duration: 2 hours in each of the three directions. 

The equipment should not be in operation during the test 
but should comply with the requirements in the MOBITEX 
terminal specification after the test. 
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2 POWER SUPPLY 

2.1 Nominal voltage 

The nominal voltage is optional and should be stated by 
the manufacturer. 



2.2 Voltage limits 

Equipment designed for working from lead acid accumulators 
in a vehicle should comply with the specifications when 
the voltage varies from 0.9 to 1.3 times the nominal 
voltage. 

Equipment designed for operating on an alternating voltage 
should comply with the specifications when the voltage 
varies by +10*. 

If these limiting values are exceeded, error functions 
which can interfere with the operation -of the network 
should not occur. 



3 HARKING 

The equipment should be clearly marked with the 
manufacturer, type designation, serial number, approving 
text {"Approved by ... ") and registration number of the 
type approval. The marking should be engraved on metal and 
permanently fixed to the equipment. 

The mobile terminal's subscription number should be 
clearly visible or accessible. 



3.1 Electronic serial number check 

The serial number should .be stored together with the 
terminal subscription MAN and permanently in such a way 
that they are impossible to change by software or by 
unauthorised persons, preferably in enchrypted form. 

The serial number of the equipment should be checked in 
the terminal against the serial number stored together 
with the MAN at power on. If the numbers are not equal, it 
should be impossible to use the equipment. 

In addition, the serial number (ESN) is sent to the 
network at "activation", to be checked with the serial 
number stored in the network (see reference Rl-09). 
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4 CONTROLS 

There are no requirements for type approval of controls. 
There are certain recommendations however. 

If number keys for number keying are used, they should 
comply with one of the following minimum configurations. 



12345*AB 
67890#CD 



1 2 
3 4 
5 6 
7 8 
9 0 
* # 
— A B 
C D 

The following recommendations apply for the A, B, C and D 
keys. The D key should have the data send function. If 
there is a speech facility, key C is used for "speech 
request". The key should be marked with T. Keys A and B 
can be used for status or another function and marked 
according to use. 

International standards should be followed if a completely 
alphanumeric keyboard is used. The number keys on the 
keyboard can then be used for number keying as well. 



1 2 3 A 

4 .5 6 B 

7 8 9 C 

* 0 # D 



5 INDICATORS 



An indicator with yellow or amber colour should indicate 
when the power is switched, on. 

An indicator with green colour should indicate with a 
steady light when the mobile terminal is in contact with 
the HOBITEX network and with a twinkling light when it is 
not (base search mode). 
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6 TYPE APPROVAL TESTING 



Except the equipment described in the chapters below, 
requirements may be specified by the network operator 
(please refer to reference Rl-06) for equipment such as: 

- Portable antennas 

- Cabling and terminations 

- Terminal display 



6.1 Equipment to be type approved 

The type approval test applies to the radio equipment and 
to the physical, link and network layers of the mobile 
-equ-ipraent--according to these specifications. Application 
layer functions are only tested if under special 
requirements when installed. 

The type approval only applies to the software tested. If 
a change is made in any software stored in the same 
storage unit as the software handling the tested 
functions, -a new type test must be made. The testing 
authority should determine at its discretion and based on 
documentation of the modifications, wether new 
measurements are necessary for a new approval. 

Optional terminal equipment to be connected to the radio 
control unit is not type tested. 



6.2 Normal test conditions 

The mobile terminal should be tested in the normal 
environment stated above. The specified data should be 
complied with for all combinations. 

Terminals designed for operating on lead acid accumlators 
in vehicles should be tested at 1.0 times the nominal 
voltage. 

The terminal should be ready for operation within 1 minute 
of switching on the power. 



6.3 Extreme test conditions 

Additional environmental requirements can be made' in 
reference Rl-06 (Network operator information). 



AiS2 3I5Ja 
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The mobile unit should be tested at the lower and upper 
limits in the temperature and voltage ranges" stated above. 

Before testing is carried out, the equipment should have 
achieved thermal equilibrium in the test chamber. The 
power supply should be switched off during this period. 
Measurements should be carried out in such a sequence and 
with relative humidity controlled so that excessive 
condensation does not occur. 

Testing at the upper temperature limit should begin with 
the sender in the send position for 1 minute and receiving 
for 4 minutes after which measurement's are carried out. 

Testing at the lower temperature limit should commence 
1 minute after switching" on the power supply. 
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6.4 Test connections, interfaces and controls 

For the type approval test, the mobile terminal should be 
equipped with test ' connections and manual controls to 
permit the measurements that are necessary to verify that 
the specification requirements are complied with. This 
applies particularly to the requirements stated in 
'reference Rl-18 {"Radio equipment, mobile terminals" and 
"Measurement methods"). These connections and controls can 
be implemented by external test adaptors during the test. 

For the type approval test, the equipment should also be 
equipped with the "Machine interface (MASC)" as described 
in reference Rl-19 ("Other interfaces, mobile terminal", 
minimum basic and type test functions). This interface can 
be implemented by an external test adaptor during the 
test. 

Equipment intended to be used as partially active in 
— "MOBITEX should Be" possible to operate as a normal mobile 
terminal during the tests, i.e. continuously listening to 
MOBITEX. 
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7 MOBITEX TERMINAL SPECIFICATION REFERENCE LIST 

This document includes a number of references, made to 
other sections in the terminal specification. The list 
below shows these references, together with the page(s) 
they are made on. Please note that a section could be 
referred to several times on the same page. 

Rl-06, 6 

Rl-09, 4 

Rl-18, 8 

Rl-19, 8 



Below are the reference designations listed. 



Reference , Section 

Rl-01 Arrangement of the documents 

- ^Rl-02 MOBITEX System description 

Rl-03 General description of terminals 

Rl-04 Terminology 

Rl-05 References 

Rl-06 Network operator information 

Rl-08 Application layer 

Rl-09 Network layer 

Rl-11 Interface requirements,, fixed terminals 

Rl-12 Other requirements, fixed terminals 

Rl-16 Link layer, mobile terminals 

Rl-17 Physical layer, mobile terminals 

Rl-18 Radio equipment, mobile terminals 

Rl-19 Other interfaces, mobile terminals 

Rl-20 Other requirements, mobile terminals 
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